Writing Unit Tests
Unit tests for a module shouldn’t be located far away from the module. In small projects unit tests can be included in the module itself. But for larger projects, it’s better to move them into a separate directory. But why do we say that it should be closer? Because, anything that’s not easy to find will not be used!
There are two advantages of doing this:
But providing unit tests is not only enough. We have to run them often, every time when we make changes to our code. It helps us to confirm that the class passes its tests once in a while.
Test Harness
When we write a lot of test code, it’s always better to have a standard test harness to create a testing environment. This helps to make our life easier.
A test harness can be implemented in the same language used for coding, or using makefiles and scripts. It can handle common operations like logging status, analyzing output for expected results and selecting and running the tests. It can also be GUI driven.
No matter however it is implemented, a test harness should have the following capabilities:
Tests should be always composable. That means, a test can be composed of subtests of subcomponents to any depth. In this way, we can select the complete test, or individual parts of the test depending on the requirement at that time.
- summary of Writing Unit Tests & Test Harness, from The Pragmatic Programmer: from Journeyman to Master
Unit tests for a module shouldn’t be located far away from the module. In small projects unit tests can be included in the module itself. But for larger projects, it’s better to move them into a separate directory. But why do we say that it should be closer? Because, anything that’s not easy to find will not be used!
There are two advantages of doing this:
- It gives some examples on how to use all the functionalities of the module.
- A mean to build regression tests for validating the future changes in the code.
But providing unit tests is not only enough. We have to run them often, every time when we make changes to our code. It helps us to confirm that the class passes its tests once in a while.
Test Harness
When we write a lot of test code, it’s always better to have a standard test harness to create a testing environment. This helps to make our life easier.
A test harness can be implemented in the same language used for coding, or using makefiles and scripts. It can handle common operations like logging status, analyzing output for expected results and selecting and running the tests. It can also be GUI driven.
No matter however it is implemented, a test harness should have the following capabilities:
- A standard way to specify setup and cleanup.
- A method to select individual tests or all the tests.
- A method to analyze output for expected or unexpected results.
- A standardized form of failure reporting.
Tests should be always composable. That means, a test can be composed of subtests of subcomponents to any depth. In this way, we can select the complete test, or individual parts of the test depending on the requirement at that time.
- summary of Writing Unit Tests & Test Harness, from The Pragmatic Programmer: from Journeyman to Master
No comments:
Post a Comment