Write your tests first.
Begin with the end in mind. It’s one of the 7 habits of highly effective people. When you are working towards a definite goal, you can formulate a plan on how to get there. One should undoubtedly design a solution before programming the implementation.
Start with the expected behavior. This should come straight from the story; as a role, given some conditions, when I do something, I should see this result. If you wrote the story into a behavior test, you would already be a long way along. Tools like cucumber and gherkin stress this idea, by translating human-readable language into test details.
Moving from the test of behavior to the test of units is the tricky part. That is where you are forced to make some decisions about the technical design of the application. You need to determine what objects you are going to have in play and how they will interact with each other. This, in turn, leads to the definition of interfaces.
As you develop your collection of objects, interactions, interfaces, and methods, you can start to create tests for how these methods should perform. The first step is to simply identify all of these tests, by giving them good names. With that, you can tell at a glance if you’re covering all the necessary scenarios.
Only after the test is fully fleshed out will you create any code that is part of the actual implementation. This may seem like a lot of prep work to get code written, but when you do it this way, the time spent in implementation is a lot shorter and usually requires much less rework.
Today's Card 