I have just discovered a new way of doing TDD and I am calling it Debugger Driven Development.
This is how you do Debugger Driven Development.
1) Write a test which calls some method that does some complex calculation.
2) Add an assert statement with a null expected value.
3) Run the test in the debugger get the actual value returned by the method and use it for the expected value.
Debugger Driven Development is just so wrong. It does have some value for regression testing assuming your code is correct but it will cause big problems if it's incorrect. What you should do is always calculate the expected value by hand. That way if the value returned by your program matches your hand calculation their is a high probability that your code is correct. Doing Debugger Driven Development proves nothing.
Subscribe to:
Post Comments (Atom)
2 comments:
But why it's wrong? What will change if you will make a guess or calculate it manually?
The more important question is - should this piece of business logic be covered with test?
If there is a possibility to screw up input or output method parameters in future implementations, then debugger-driven testing is as good as any other methods.
http://lazyloading.blogspot.com/2008/04/resurfacing.html
This reminds me of how college students write code. Throw a bunch of lines together, hit run, follow the error to the line in question, "fix" that line, hit run again, repeat. Usually it either ends with a program that somehow works despite not being decipherable, a brittle but working (for this particular input) solution, or an undebuggable hopeless mess.
Post a Comment