--------
What is our programming / development style? In other words, how do we typically implement and verify business (i.e. non-UI) rules? 5 options I’ve seen / done:
- Modify existing function or add a new one then open a web browser, click a button, then verify on the web page
- Modify existing function or add a new one then open a web browser, click a button, then verify in the database (similar to using SQL Profiler)
- Add Response.Write, STOP, etc. statements in code, or add CSS around an element to call attention to it and go from there
- Write a bunch of new classes / methods / etc. in an effort to finish a task before a deadline, then come back to them weeks later and write some xUnit tests to boost code coverage from zero to x…. only to find out when writing your tests that your design / architecture is far from ideal. aka TLIE (Test Last, If Ever)
- Open xUnit, create an automated test, make it pass, and then change the necessary code base, cry tears of joy… aka TDD
- is repeatable?
- leaves a signpost for future developers, documenting that a certain feature exists?
- provides an example API usage for future developers (including myself in that audience)?
- is fast? (and therefore gives you the ability to try several implementations when you have a few options in mind and aren’t sure which not only works but is best)
- is isolated (can happen even if everything else is broken)?
- does not require (much, if any) human work?
- gives us confidence when making any change, no matter the size?
Why is writing the automated test important at all?
- Automated tests help us verify that we definitely know what we think we know. Adding more helps convert “what we don’t know” to “what we know” …. err, something like that.
- Tests provide living and up-to-date documentation in source control.
- Especially in our code base, changing almost anything is stressful. Automated tests are stress management tools. Passing automated tests eliminate the stress of “what we don’t know” and gives us the courage to focus on our real passion, which is adding more value to our customers. [If you feel no stress at all when debating changing code in your current production codebase, please leave the room after reading the following out loud: I, _________, apologize to the entire company for the future hotfixes I am about to create a need for. I apologize to our production release team, to support, my fellow developers, and to our customers. I have stocked the kitchen with Red Bull, Tylenol, and Prozac. I will begin working on handwritten letters of apology immediately.]
- “In TDD, the tests are a means to an end – the end being code in which we have great confidence.”
- You tell me
- Write new code only if an automated test has failed
- Eliminate duplication
- Red
- Write the test first to tell the story of what we wish to implement,
- how we wish our API to look (Beck calls this “the perfect interface for our operation” and tells us to “Invent the interface you wish you had.”),
- what will cause the test to pass (assertions),
- Write the assert statements first so you know when you are done.
- help define clearly what is in scope and what is not.
- This gives us a concrete measure of failure!
- Green
- Fix the failing test to pass to know with certainty the given story has been completed
- Even if it’s ugly, just focus on turning the red bar to green fast
- This gives us a concrete measure of success!
- Refactor
- Keep a tidy house and make sure the green bar still exists afterward
- If you used constants to get a single test to pass in step 2, add another assertion and generalize the code to work for all scenarios (triangulation).
- Change the code but not the outcome or business rules. This is a stressful and time-consuming exercise unless you have tests as a safety net to guarantee even massive code changes don’t cause a change the in code’s behavior as the end user sees it.
- Design. TDD is continual design. Design is fluid and never finished. Features (and scope) are complete when all tests pass, but design goes on like the Energizer Bunny. Do not be surprised to see your design veer wa(aaaaaa)y off course from what you originally thought you should originally end up with.
- Design is mandatory instead of an afterthought
- You start with the world’s greatest API for the given problem and only back down from that when necessary
- Tests are a way to identify scope boundaries and help us stay within them while we develop. We isolate a tiny low-stress situation, and only move outside of that scope when we are ready to write a new test. When we have a failing test that we need to make a passing test, we cannot ourselves to get sidetracked by, “oh yeah, I also need to implement this for this project…” and then we’re 30 minutes later before we remember what we were working on. In this way, writing tests first eliminates waste. (!!!!!)
- Arrange – create some objects (setup your condition)
- Act – stimulate them (force the situation under test to execute)
- Assert – check the results
Before beginning any task, write a list of all the tests you know you will have to write. After you have Red>Green>Refactored a story off of your to-do list, select the next item from the list based on:
- level of confidence (am I certain I can make this work?)
- will this teach me something?
Some things you might already know but need to reconsider:
- Make sure your tests are isolated. One failing test should not cause 3 others to fail. The order in which the tests run should also not matter.
- Change the voice inside your head from “how do I implement feature X” to “how do I test my implementation of feature X” any time you open the IDE and consider typing.
- You decide your velocity with TDD. If you find yourself getting annoyed at running tests after changing every single line of code that you know will not break a test (such as changing a variable name inside a 4 line c# method) then allow yourself to make bigger incremental changes before re-running tests. If you find yourself stressing over whether all your tests will pass or not, slow down. Redline the Bronco like OJ on a clear sunny day and slow down when the road gets icy.
- Every time you have a test fail unexpectedly, write a new test to document what was just discovered. It may mean you just found a bug.
- Along the same lines, take the time to discover why something works when you think it shouldn’t.
- Along the same lines, if you find a refactoring which your current tests do not demand, write another test.
- Your test code may actually be as many lines as the code you are adding. This is not a bad thing.
- Doesn’t this mean my output is going down? When answering that question, be sure to take debugging time, integration, and code explanation / learning into consideration. (Just because something makes sense to you doesn’t mean it will be easy for someone else to learn… or even for you to recall in the future when adding feature Y to the codebase built for feature X. Your tests at least document your obvious-now-but-likely-to-become-confusing-later solution.)
- Do not be afraid to delete assertions, tests, or methods as part of refactoring; however, be confident that a test is obsolete before deleting. If the test does not give you any more confidence by existing, and it doesn’t communicate anything new to the reader of the test that they can’t learn in another test, it can be deleted.
- TDD does not in any way replace or eliminate a need for performance / stress / usability testing.
- 100% test coverage does not mean 0 bugs.
- Can we change the meaning of 1 line of code and then have a broken build? If not, we need another test. In other words, if we change line 873 (umm, first of all, we should never have a line 873, but that's a different discussion...) of ____.cs to say x = true instead of x = false, we should have a failing test.
I think one of the most potentially difficult things about TDD is to let yourself solve the problem simply and then make it as pretty as you want to. When you solve it simply with passing tests, you can then change the solution to be reusable, decked out with patterns, etc. and be confident that the more complicated solution still solves the problem. In other words, don’t worry about it being pretty right out of the gate. Worry about solving the problem by making the test pass, and then let the patterns or perfection reveal itself through design changes, aka refactoring. Beck says this specifically in reference to the Template Method pattern, “Template methods are best found through experience instead of designed that way from the beginning.” but I think it applies to all (err, most?) patterns. He later states that extracting too many methods can lead to the reverse (inlining methods) when you think start off with a Template Method instead of following the above advice… so save yourself the time and let the patterns reveal themselves instead of creating patterns for the sake of patterns.
