Back to VSLive! San Francisco Show Daily Home
Tips for Test-Driven Development
Let test-driven development direct your software design.
by Jimmy Nilsson
VSLive! San Francisco, March 24, 2004
Note: At VSLive! San Francisco, Jimmy Nilsson is presenting "Putting Test-First Design Into Practice," on Thursday, March 25. He offers some quick pointers from that session for getting started with test-driven development.
Take the Initial Step
Deciding to write automatic unit tests to test your real code is the first important step. The next natural step is to apply test-driven development (TDD), which means that you write tests before real code and let the tests drive your design. Using TDD will facilitate automatic testing. Without TDD, it's likely you won't write any tests when time is scarce.
White Box vs. Black Box
A common question regarding TDD is whether you should use white-box or black-box testing. Should you test private methods or just methods that are publicly available (such as methods in the interface)?
I prefer to use black-box testing and test only the public interface with my automatic unit tests. The negative effect of this is that the public interface often gets a bit larger. I usually need to expose sub results as property gets. The bigger interface is read-only, so it's not a major problem. Sure, there's a risk of showing too much of the algorithm, but the larger interface often proves useful for the real consumer.
I also use ordinary assertions (such as System.Diagnostics.Trace.Assert) for pre- and post-conditions in my methods (similar to Design by Contract by Bertrand Meyer). Of course, those assertions will help when running the automatic unit tests too.
Failure First
When you start to use TDD, your first mission is to ensure your test fails. Then you write the code needed to make the test execute successfully. If you skip the first step, you risk not testing something you think you're testing. Been there, done that.
Go With the Flow
Even if you like and use TDD, certain situations mandate taking a closer look at the flow of a certain part of your code. Sure, you can kick up the debugger when you run your automatic tests, but other solutions exist too. A simple one is to put Console.WriteLine statements in your code. If you use NUnit, you will find the output at the Console.Out tab.
For more about test-driven development, also see my blog posts in the VSLive! Speakers blog:
About the Author
Jimmy Nilsson is the owner of the Swedish consulting company JNSK AB and has been working with system development for more than 15 years. Jimmy has written numerous technical articles and is the author of .NET Enterprise Design with Visual Basic .NET and SQL Server 2000.
Back to top
|
