Unit testing in Coders at Work
gigamonkeys.com
Unit testing in Coders at Work
1–10 of 88 posts
Re: Unit testing in Coders at Work
#2I sit somewhere in the middle. Unit testing GUI code is going to slow you down. Unit testing your core algorithms is essential. That is the stuff that must never break, and where breakages would not be immediately detectable. The unit tests ensure that you are always sure that that code works.
(Real world example; testing somewhat hairy parsing code: http://github.com/jrockway/moosex-runnable/blob/master/t/arg... I test every case I could come up with, so I could be sure that it works. Better to spend the time typing this file than to be hit with a weird misparse on the command-line, where you are probably not in the mood to fix the parser.)
On top of the unit tests, I do integration tests, to make sure sections of my app mostly work together. This is somewhere below "Request -> Response" and somewhere above the individual routines/classes. In the web app case, this is mostly "instantiate an object graph; call the methods that provide data to the rendering functions; make sure the results make sense". (I assume my template renderer and object database work; those have their own test suite, after all.) I also test stuff like typical sequences of actions that share some state (usually "the session"). I neglected that once and it caused me lots of problems.
But anyway, GUI testing == waste of time. As long as the buttons you click generate the right events, the GUI works. This is the sort of app Zawinski was working on, and this colors his thoughts on testing accordingly. Your mileage may vary.
Re: Unit testing in Coders at Work
#3The part about TDD in the interview with Peter Norvig really jumped out at me, too. A passing test doesn't always mean anything important has changed - like most other programming tools, there are circumstances where unit tests just create the illusion of progress. I also remember Norvig saying* that sometimes the scope of pass/fail tests may be too narrow, because sometimes having 18 of the first 20 results be reasonable is good enough, but typical testing packages aren't really structured to accommodate probabilistic thinking. Certainly more relevant for some problems than others, but interesting nonetheless.
I've seen major benefits from automated testing, and I'm convinced they're a net win (especially for maintenance), but I also think that being dogmatic about any particular testing methodology (TDD, etc.) is going to be counterproductive sometimes.
* I don't remember if it was from the same book, PAIP, AIMA, or something else - I've been bouncing around in several AI and Prolog-related texts lately.
Re: Unit testing in Coders at Work
#4If you enjoyed seeing the contrast in approaches between Norvig and Jeffries, you may also find the following interesting -- calculating bowling scores in
1. OCaml, no tests: http://alaska-kamtchatka.blogspot.com/2009/07/disfunctional-...
2. Clojure with unit tests: http://blog.objectmentor.com/articles/2009/07/19/uncle-bob-j...
Re: Unit testing in Coders at Work
#5The part about TDD in the interview with Peter Norvig really jumped out at me, too. A passing test doesn't always mean anything important has changed - like most other programming tools, there are circumstances where unit tests just create the illusion of progress. I also remember Norvig saying* that sometimes the scope of pass/fail tests may be too narrow, because sometimes having 18 of the first 20 results be reaso…
The Norvig points were particularly thought-provoking. How do you tell if google is returning the correct result.
The other is that starting a unit test without knowing what you are aiming for (e.g., the puzzle solver) you may not get there, and TDD won't help you.
Re: Unit testing in Coders at Work
#6I sit somewhere in the middle. Unit testing GUI code is going to slow you down. Unit testing your core algorithms is essential. That is the stuff that must never break, and where breakages would not be immediately detectable. The unit tests ensure that you are always sure that that code works. (Real world example; testing somewhat hairy parsing code: http://github.com/jrockway/moosex-runnable/blob/master/t/arg... I t…
Why exactly is unit testing of GUI components a waste of time?
Re: Unit testing in Coders at Work
#7fwiw, I wrote the original blog post (that Norvig was speaking about in his interview) which compared the Sudoku efforts of Norvig and Jeffries) - http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s....
Re: Unit testing in Coders at Work
#8When I started programming, I think someone (most likely my father), told me that most of my time writing code should be spent thinking about how to solve the problem (not writing code).
What I am concerned about is that methodologies end up trying stand in for this old fashioned technique of Thinking Really Hard and Being Smart. (TRHBS).
You'll notice that Norvig follows the TRHBS methodology. (He is a serial TRHBSer).
Anyway, I guess the difference is that I see TDD as an implementation strategy for when you already know what the answer to the problem is, and are having trouble writing the code to implement it.
(Although sometimes that is a clue that you are doing it wrong... Whenever I see old code with a lot of debug printf statements, I know it is going to be a much more complicated answer than is probably actually required, I can't imagine it is much different with unit tests).
-j
Re: Unit testing in Coders at Work
#9I sit somewhere in the middle. Unit testing GUI code is going to slow you down. Unit testing your core algorithms is essential. That is the stuff that must never break, and where breakages would not be immediately detectable. The unit tests ensure that you are always sure that that code works. (Real world example; testing somewhat hairy parsing code: http://github.com/jrockway/moosex-runnable/blob/master/t/arg... I t…
Why exactly is unit testing of GUI components a waste of time?
They aren't safety critical and you can test them by using the GUI.
Re: Unit testing in Coders at Work
#10That was a fabulous analysis. For my part, I can't quite figure out why people seem to get emotional about TDD one way or the other. If it helps you, great. If not, ditch it. Do people work in environments where they'd like to avoid TDD but are forced to work that way? Or vice versa?