Comments on: Unit Testing http://mjtsai.com/blog/2005/09/23/unit-testing/ Wed, 09 Jul 2008 02:01:17 +0000 http://wordpress.org/?v=2.5.1 By: Brian White http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-22101 Brian White Mon, 27 Nov 2006 03:34:11 +0000 http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-22101 I'm not an advocate of TDD, but I am an advocate of <a href="http://blog.riverworth.com/index.php/2006/11/23/the-beauty-of-self-testing/" rel="nofollow">automated unit testing</a>. You don't have to do the first to reap the benefits of the second! Built-in self tests may save some time during development, but save huge amounts of time down the road. I'm not an advocate of TDD, but I am an advocate of automated unit testing. You don't have to do the first to reap the benefits of the second! Built-in self tests may save some time during development, but save huge amounts of time down the road.

]]> By: Michael http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9713 Michael Tue, 04 Oct 2005 20:39:29 +0000 http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9713 Ryan: I like TDD, and I use it. I just think that some of the examples used to illustrate it go too far. I'll write the tests for a method before writing the method. But I think it's a waste of time to write a trivial failing test and then watch it fail to prove that I need to write the method in the first place. Likewise with doing the minimum amount necessary to make a test pass (i.e. the test failed because there was no foo() method, so now let's write a foo() that always returns 0). I appreciate that in theory TDD lets you work in steps as small as you like, but I don't think that level of pedantry is helpful in real development. Ryan: I like TDD, and I use it. I just think that some of the examples used to illustrate it go too far. I'll write the tests for a method before writing the method. But I think it's a waste of time to write a trivial failing test and then watch it fail to prove that I need to write the method in the first place. Likewise with doing the minimum amount necessary to make a test pass (i.e. the test failed because there was no foo() method, so now let's write a foo() that always returns 0). I appreciate that in theory TDD lets you work in steps as small as you like, but I don't think that level of pedantry is helpful in real development.

]]> By: Ryan Platte http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9711 Ryan Platte Tue, 04 Oct 2005 19:42:27 +0000 http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9711 Hey, I detect a bit of a straw-man argument with regard to test-driven development (TDD). I appreciate your allowance that perhaps it isn't as bad as you allege, but with a followup comment chiming in, I wanted to address this. Yes, TDD writes tests first, including tests for functionality that doesn't exist yet. But that's not some sort of pedantic exercise. It's analogous to a mountain climber who makes it a practice to keep three appendages touching the surface at all times. Of course that climber will do some maneuvers that involve more than one appendage moving at a time, but the point is to define 'normal' and 'safe' and keep to that in the normal case. Doing full-on TDD with refactoring all the time buys you very well-factored code that's easy to test further and easy to change. Look at Gus's post, linked in the previous comment. The place he got to is the place consistent TDD will keep you. Hey, I detect a bit of a straw-man argument with regard to test-driven development (TDD). I appreciate your allowance that perhaps it isn't as bad as you allege, but with a followup comment chiming in, I wanted to address this.

Yes, TDD writes tests first, including tests for functionality that doesn't exist yet. But that's not some sort of pedantic exercise. It's analogous to a mountain climber who makes it a practice to keep three appendages touching the surface at all times. Of course that climber will do some maneuvers that involve more than one appendage moving at a time, but the point is to define 'normal' and 'safe' and keep to that in the normal case.

Doing full-on TDD with refactoring all the time buys you very well-factored code that's easy to test further and easy to change. Look at Gus's post, linked in the previous comment. The place he got to is the place consistent TDD will keep you.

]]> By: Michael http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9246 Michael Sat, 24 Sep 2005 15:19:01 +0000 http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9246 Other people respond: <a href="http://www.friday.com/bbum/2005/09/24/unit-testing/">Bill Bumgarner</a> <a href="http://www.livejournal.com/users/chanson/121747.html" rel="nofollow">Chris Hanson</a> <a href="http://www.rhonabwy.com/mt/archives/2005_09.html#002662" rel="nofollow">Joe Heck</a> <a href="http://www.approachingnormal.com/articles/2005/09/24/wil-shipley-on-unit-testing-and-why-hes-wrong" rel="nofollow">Larry</a> <a href="http://www.gusmueller.com/blog/archives/2005/9/23.html#1333" rel="nofollow">Gus Mueller</a> <a href="http://rentzsch.com/links/shipleyOnUnitTesting" rel="nofollow">Jonathan Rentzsch</a> Other people respond:

Bill Bumgarner
Chris Hanson
Joe Heck
Larry
Gus Mueller
Jonathan Rentzsch

]]> By: Chris http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9203 Chris Fri, 23 Sep 2005 19:54:31 +0000 http://mjtsai.com/blog/2005/09/23/unit-testing/#comment-9203 Agreed. Test-driven development (in the non-anal-retentive sense: a suite of tests for an array class is probably more useful than a test for the existence of a method, for example...) is excellent; it means avoiding a lot of debugging pain afterwards. It's improved my productivity quite a bit. And, to be honest, Omni's software was never bug-free or even close, in my experience. I had many crashes with older versions of OmniWeb (pre-WebKit). I have also found that automated unit tests save a lot of time in testing that your testers could otherwise use to help you improve the product... Agreed. Test-driven development (in the non-anal-retentive sense: a suite of tests for an array class is probably more useful than a test for the existence of a method, for example...) is excellent; it means avoiding a lot of debugging pain afterwards. It's improved my productivity quite a bit.

And, to be honest, Omni's software was never bug-free or even close, in my experience. I had many crashes with older versions of OmniWeb (pre-WebKit). I have also found that automated unit tests save a lot of time in testing that your testers could otherwise use to help you improve the product...

]]>