I will just explain my process and why I call it what I call it and let you do with that information what you like…
I build outside-in, however I start with the repl and unit tests. I also build modular so I think that changes my outcome from a more coupled coder. Let me give an example…
I have a rails app that already exists. In it, I need to add a new bit of functionality to process a file the user uploads, lint, and store it in a persistence layer.
I would not just start building models and controller here. Instead I would start with a PRO (pure ruby object), what object and how? I start with the entry point, the file the user is going to upload.
There I draw a boundary. My code lives here, while rails lives up there somewhere. I do not need to care about rails at this point, I only need to care about the file… There is no spoon.
So the requirements are that given a file I need to make sure it is valid, then I need to store the values into a database structure of some time.
That leads me to qualify what the file is, what it looks like, which means I need an example from the business or a specification in which to build my sample file. The former is always better.
Now I know what is valid and invalid, and what the structure of the data I am storing looks like, it’s time for a test. Notice up til now I have written 0 production code.
My object would probably start life named
UserSubmittedFilePersister and that would evolve over time as I learn more about the domain I am solving. But back to the tests, with the above name chosen, based on the nouns and verbs.
So my first unit test would be to verify the structure of the data. I would use the example as fixture 1 and mutate it in 1 incorrect way and save it as fixture 2. Then I simply assert given a valid file, the objects single public method will indeed validate the file.
Then I write the production code to make that pass. Then I write a test to fail it based on the ‘bad fixture’. Then I continue on until the validation part is flushed out.
Since validation and persisting arent the same concern, I would break that production code and tests into a new object…
ValidateUserSubmittedFile. The tests will pass again after the rename.
Now I plug that validator into the original object
UserSubmittedFilePersister and continue the cycle to define what
Once my domain logic is all flushed out minus the file origin and the actual database save part, it is time to write integration tests to help me integrate it into my rails app. I already know the interface and the contract at that point, so it is easy.
Only at that point do I attempt to integrate it. The integration should not force design on the domain logic in my not so humble opinion.
Some would call this bottom up. I of course, would disagree, and have.