... | ... | @@ -9,13 +9,13 @@ Some of the styles derived from BIND 9 that are often forgotten or misunderstood |
|
|
|
|
|
# Test-Driven Development
|
|
|
|
|
|
We use [test-driven development](https://en.wikipedia.org/wiki/Test-driven_development) in the Stork project. We require writing unit tests together with the code. The developers should write the unit tests before the implementation and make sure the tests initially fail. Implementing the code should cause these tests to pass. Creation of the tests after the implementation poses a risk that the tests do not correctly validate the implementation and pass regardless.
|
|
|
We use [test-driven development](https://en.wikipedia.org/wiki/Test-driven_development) in the Stork project. We require writing unit tests together with the code. The developers should write the unit tests before the implementation and make sure the tests initially fail. Adding the implementation should cause the tests to pass. Writing the tests after the implementation poses a risk that the tests do not correctly validate the implementation. In some cases the tests can always pass, even when the implementation doesn't exist yet.
|
|
|
|
|
|
The unit tests should cover all functions, and our linters report errors when they detect missing coverage. However, it is essential to focus on testing all cases of complex functions rather than writing many tests for trivial functions.
|
|
|
The unit tests should cover all functions, and our linters report errors when they detect missing coverage. However, it is essential to focus on testing all cases of complex functions rather than writing many tests for trivial functions. If a function is a trivial getter it probably doesn't even require a dedicated test. It suffices if the getter function is called in some other tests to get the value it returns.
|
|
|
|
|
|
There are cases when it is hard to write tests for some functions. For example, writing a unit test for a main() function may be hard. In legitimate cases, it is ok not to write a unit test for a function, and it should be decided on a case-by-case basis. Such cases should be covered in the system tests instead.
|
|
|
There are cases when it is hard to write tests for some functions. For example, writing a unit test for a `main()` function may be difficult. It may also be difficult to write a unit test for a function that relies on a specific configuration of the host machine (e.g., existence of some network interfaces). In legitimate cases, it is ok not to write a unit tests for such functions. Testing them should be covered in the system tests instead.
|
|
|
|
|
|
If writing a unit test for some code is hard or impossible, a developer should consider restructuring the code to allow testing.
|
|
|
If writing a unit test is hard or impossible, a developer should consider that the code may have a bad design. Restructuring the code can sometimes allow testing at least selected parts.
|
|
|
|
|
|
# Documentation
|
|
|
|
... | ... | |