One of hardest things to learn/coach about TDD is the thought process and the stringing together various concerns into one coherent driving force that keeps you moving in a good direction. All the things that have been mentioned so far are important but I find what is not captured very well is the conversation that happens when you're doing TDD.
Yes; this is the same strategy ZOMBIES follows (Zero One Many Boundaries Interfaces Exceptions Simple Scenarios).Steven Solomon wrote:tests are written from smallest cardinality to largest.
There are tons of micro-decisions that are visible in even the simplest test:
For instance the name of totalIsZero_forEmptyList is constructed that why due to my desire to express both the pre- and postcondition in the test name, the Cart.total method is a static method on a class in order to limit the introduction of state. Tiny decisions like this are made once,
Steven Solomon wrote:I based this decision on cardinality of tests on proof by induction. I'll have to check out this Zombies approach
If I am scanning a list of tests, I want to be able to quickly see at a glance whether I have a test for all of the scenarios I would expect. By shrinking the surface area of what readers need to comprehend, I can allow them to focus on what I want them to read more easily.
To your point about implementation details, I think this is a great conversation to have... This is the kind of discussion I want to bring to our pairing session.
In my opinion, names depend on the domain of the system and whether the design is more FP or OO. For this test I happened to write it in more of an FP way. Here there is no concept of a cart, it is just a list of products. In fact, I think the Cart is the thing that is misnamed, rather than the test. The total method could take any list of any Products and total them. The list could represent a wishlist, a set of products in a customer's cart, or a list of products in a bundle that we want the customer to buy together.
Steven Solomon wrote:
Another piece of advice... is to not worry about making the Right Decision TM when you are writing code with TDD. Just make a decision about the structure of the code, and lean on refactoring to correct decisions that feel wonky.