~ryanlowe/blog: Software Testing and Creativity

Software Testing and Creativity

Some developers think that if they are forced to test their software seriously THEMSELVES (ie. not with a separate testing group), it may stifle their creativity in some way. Developers can get into a "hacking zone" and just produce produce produce. How do you know what you produce isn't a load of bung? With tests.

With test-driven development, you can "define" your system requirements in terms of tests. Then use your creativity to make these tests pass, refactoring your solution as you progress. Since you are confident that what you have is always correct after you refactor because of the tests, it allows you to take larger refactoring risks than normally possible. You have less to keep track of in your head - "will feature X still work if I do refactor Y?" - and you have more brain horsepower for writing a creative solution to the problem ...

... which is making all of the tests pass. :)

So writing your own tests actually allows you to be *more* creative because you have the safety net and less to worry about. Unless you don't care about the quality of the code you produce - in which case you are on your own.

Posted at April 06, 2003 at 07:08 PM EST
Last updated April 06, 2003 at 07:08 PM EST

Comments

It's like writing an essay. The first try is raw and pure. The second pass is being realistic. The third pass is getting rid of the crap and cleaning it up. The forth is polishing.

There's always stages in producting *anything* Nobody can make flawless things on their first try. Iteration and examination (testing) is always necessary.

» Posted by: roy at April 7, 2003 12:48 AM

That's not really a great analogy for test-driven design but good for "iterative development". Each iteration has a solid set of defined requirements that you can test against, you may refactor the code that passes these tests but the requirements/tests never change in an iteration (ideally).

When the next iteration comes around, user feedback will steer you in another direction. This means new tests and/or changing the old tests to fit the new iteration's requirements.

I hope that helps to differentiate the two.

» Posted by: ryan at April 7, 2003 12:55 AM

that is so cool, and i am really excited that you seem to be grasping this TDD sheeat full force - way to go

» Posted by: andrew at April 7, 2003 03:48 PM

roy, i'd like to build on your analogy... indeed I agree that your comparison is like an iterative approach to software... now consider this...

pretend that you are writing an essay to prove a point (any point) - and that you have predefined points you wish to make (aka the tests) - you map out your expectations (again referring to the tests) and then start writing to fulfil your tests (aka the iterative approach)...

now lets say you want to add to your essay ... again with more tests and more writing... with an automated test suite style thingy you can easily check to make sure that you haven't contradicted yourself with the new work based on older expectations (aka making sure the new sheeat doesn't break the old)..

so having a clearly defined objective with your writing before actually writing is more closely related to test-driven design - and of course with such objectives in place you can somewhat safetly edit (aka refactor) your work knowing that the overall message is preserved

» Posted by: andrew at April 7, 2003 03:53 PM

yeah...agreed on both points...my point was not complete and thorough enough. Very basic analogy indeed.

I understand what you mean...you guys seem to really love this...all more making me want to learn CPPUnit :-)

» Posted by: roy at April 7, 2003 04:54 PM