Fog Creek Software
Discussion Board

Unit Testing the Design

A few recent threads have explored some issues of good design.  These kinds of discussions often touch on things like scalable, reusable, flexible, etc.  Anyone have good techniques for "testing" a design for these properties?  What do you look for?  How about "design smells?"

Friday, September 19, 2003

Prototype it. Maybe you can't do it well, but you very often can ballpark it. If your algorithm is a 42.5 stage magic pipeline, you can hook together the interfaces with some poor-ish implemented code. You should be able to bang out something good enough to give you an idea in a couple days.

It won't be a good solution, but it can probably tell you if you'll break down in the 100's or in the 1000's.

Not to say that this is easy: If your design doesn't lend itself to a partial implementation, you may wind up going halfway there. But that's a case by case judgement.

Mike Swieton
Friday, September 19, 2003

See for a discussion on frameworks.  As should be clear, they would be close to impossible to unit test for...

On the other hand, performance testing via unit tests may hold some promise.  The key would be to test the variable unit.  So lets say that 10 papes per second need to be served.  First we could test the amount of time it takes to receive, generate, and send ten pages on the server.  During this test we could determine the amount of time used for the actual content generation by using markers.  Then when we run the unit tests on the development machine with comparable processing power and ensure that the execution time was within the needed range.  Of course if a database was being used that may introduce unknown variability that could invalidate the test.

Anyway, perhaps this will provide some food for thought.

Friday, September 19, 2003

If you have real code, the unit tests should test the design.

Try test driven development. You would be amazed at how well it works at keeping the design simple. It forces you to write clean, well designed interfaces, since your code has an extra client.

If you start off with a bad design, write a test case that demonstrates how a bit of the code should look. Then refactor until the test passes. Repeat until you have covered all your code.

Rhys Keepence
Monday, September 22, 2003

*  Recent Topics

*  Fog Creek Home