Comments on: Naming unit tests http://www.fuzzylizard.com/archives/2008/09/03/977/ Web development and design with a little VFX thrown in for fun Fri, 14 Jan 2011 22:45:58 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Alex Hung http://www.fuzzylizard.com/archives/2008/09/03/977/comment-page-1/#comment-31317 Alex Hung Mon, 08 Dec 2008 16:18:05 +0000 http://www.fuzzylizard.com/?p=977#comment-31317 I agree with Sarah. What I've found is that my unit test names are primarily driven by the story requirements. I extensively use the "Should..." paradigm to make sure I (and my pair) focus on the why, and not what or how. This way, the names tend to stay the same because I am implementing tests to confirm requirements are satisfied, and leave the implementation details to the code. I agree with Sarah. What I’ve found is that my unit test names are primarily driven by the story requirements. I extensively use the “Should…” paradigm to make sure I (and my pair) focus on the why, and not what or how. This way, the names tend to stay the same because I am implementing tests to confirm requirements are satisfied, and leave the implementation details to the code.

]]> By: Sarah Taraporewalla http://www.fuzzylizard.com/archives/2008/09/03/977/comment-page-1/#comment-28069 Sarah Taraporewalla Wed, 03 Sep 2008 19:44:58 +0000 http://www.fuzzylizard.com/?p=977#comment-28069 Perhaps if you don't know how you want the code to behave, then you haven't thought through the design of your story enough. If find if you test the behaviour, rather than what it is meant to do, then you usually know what you want to happen. Sometimes, I decide to push implementation down to other services, helpers, or lower down the stack, but I keep the original test inplace, and also have the test at the required unit level. Of course, there are always going to be those times when you really don't know how the code will hang together. Pat Kua call these times experimentation http://www.thekua.com/atwork/2008/02/05/if-you-do-test-driven-development-all-the-time-youre-doing-something-wrong/. Take his advice - use TDD when you are focused on the problem, and know how to solve it; use experimentation to find out how to solve it (and then quite possible, revert all your changes and begin TDD) Perhaps if you don’t know how you want the code to behave, then you haven’t thought through the design of your story enough. If find if you test the behaviour, rather than what it is meant to do, then you usually know what you want to happen. Sometimes, I decide to push implementation down to other services, helpers, or lower down the stack, but I keep the original test inplace, and also have the test at the required unit level.

Of course, there are always going to be those times when you really don’t know how the code will hang together. Pat Kua call these times experimentation http://www.thekua.com/atwork/2008/02/05/if-you-do-test-driven-development-all-the-time-youre-doing-something-wrong/. Take his advice – use TDD when you are focused on the problem, and know how to solve it; use experimentation to find out how to solve it (and then quite possible, revert all your changes and begin TDD)

]]>