Professional C__ - Marc Gregoire [444]
Define the Granularity of Your Tests
Before you start designing the individual tests, you need to do a reality check. Given the requirements of your component, its complexity, and the amount of time available, what level of unit testing can you provide? In an ideal world, you would write more tests than code to thoroughly validate the functionality of a program (though if it were truly an ideal world, we probably wouldn’t need tests because everything would work). In reality, you are probably already crunched for time, and your initial task is to maximize the effectiveness of unit tests given the constraints placed upon you.
The granularity of tests refers to their scope. As the following table illustrates, you can unit test a database class with just a few test functions, or you can go nuts and really ensure that everything works as it should.
LARGE-GRAINED TESTS MEDIUM-GRAINED TESTS FINE-GRAINED TESTS
testConnection()
testInsert()
testUpdate()
testDelete()
testSelect() [all of the large-grained tests]
testConnectionDropped()
testInsertBadData()
testInsertStrings()
testInsertIntegers()
testUpdateStrings()
testUpdateIntegers()
testDeleteNonexistentRow()
testSelectComplicated()
testSelectMalformed() [all large- and medium-grained tests]
testConnectionThroughHTTP()
testConnectionLocal()
testConnectionErrorBadHost()
testConnectionErrorServerBusy()
testInsertWideCharacters()
testInsertLargeData()
testInsertMalformed()
testUpdateWideCharacters()
testUpdateLargeData()
testUpdateMalformed()
testDeleteWithoutPermissions()
testDeleteThenUpdate()
testSelectNested()
testSelectWideCharacters()
testSelectLargeData()
As you can see, each successive column brings in more-specific tests. As you move from large-grained tests to more finely grained tests, you start to consider error conditions, different input data sets, and different modes of operation.
Of course, the decision you make initially when choosing the granularity of your tests is not set in stone. Perhaps the database class is just being written as a proof-of-concept and might not even be used. A few simple tests may be adequate now, and you can always add more later. Or perhaps the use cases change at a later date. The database class might not initially have been written with international characters in mind. Once such features are added, they should be tested with specific targeted unit tests.
If you plan to revisit or refine the tests at a later date, you should make every effort to actually do so. Consider the unit tests to be part of the actual implementation. When you make a modification, don’t just modify the tests so that they continue to work, write new tests and re-evaluate the existing ones.
Unit tests are part of the subsystem that they are testing. As you enhance and refine the subsystem, enhance and refine the tests.
Brainstorm the Individual Tests
Over time, you will gain an intuition for which aspects of a piece of code should turn into a unit test. Certain methods or inputs just feel like they should be tested. This intuition is gained through trial and error and by looking at unit tests that other people in your group have written. It should be pretty easy to pick out which programmers are the best unit testers. Their tests tend to be organized and frequently modified.
Until unit test creation becomes second nature, approach the task of figuring out which tests to write by brainstorming. To get some ideas flowing, consider the following questions:
1. What are the things that this piece of code was written to do?
2. What are the typical ways each method would be called?
3. What preconditions of the methods could be violated by the caller?
4. How could each method be misused?
5. What kinds of data are you expecting as input?
6. What kinds of data are you not expecting as input?
7. What are the edge cases or exceptional conditions?
You don’t need