Alex has been doing software development since 1990. His current passion is how to bring soft back into software. He firmly believes that our industry has reached the level of sophistication where this lofty goal (i.e. bringing soft back into software) is fully achievable. One of the amazing ways to accomplish that is to adopt the 'fail fast' approach by crafting a measurable goal/test and then iterating until the test passes. Following that, send the sniffing police dog to check the cargo (i.e. use mutation testing), and if the dog does not detect any illicit material, your code is optimally structured. Which means it is now back to being soft, maleable, pliable. Which means you have improved the flexibility of the business operations.
Alex is presently consulting at WorkSafeBC, an organization dedicated to ethical treatment of safe work environments in support of employees and employers in the province of British Columbia. Alex is responsible for leading and ensuring prudent software engineering practices at the organizational level.
To read more of Alex's writing on technology, visit his blog: http://digitalexprt.com/blog.html
Authored Comments
Good catch, thank you for alerting me. I have now reverted the title to its original -- "Writing unit test after writing code considered harmful in test-driven development"
No, in TDD we don’t work off of guessing. We follow the three Cs methodology, as practiced by Extreme Programming (XP). The three Cs are:
1. Card
2. Conversation
3. Confirmation examples
It starts with business formulating a hypothesis. For example, a product owner wants to grow their product and they brainstorm and arrive at a hypothesis (or two). They then write that hypothesis on a handy card.
That card then is shared with the team, and it entices further conversation. What did you mean by this, what did you mean by that, could you please clarify this part, can I suggest this idea, and so on. After the conversation gets exhausted, it should result in one or more confirmation examples. Those confirmation examples must contain concrete values.
TDD works off of those concrete values. Nothing is left to guesswork.
If the business/stakeholders are not capable of procuring confirmation examples with concrete values, it is meaningless to commence any work on implementing the business hypotheses. Because, what would you implement if you lack the specifications?
Just handing over a wish list (something like “I wish to build a product that would sell amazingly well and make me rich!”) is not going to cut mustard. A lot more specific details, excruciating minutia, must be provided before it makes sense to start building software.