« Table of Contents »
Previous Page « No Other Test Cases Are Necessary!
The Behaviour Specification Handbook
Behaviour Specifications
Developers: No Other Automated Tests!
Developers in particular need to understand that they should not write any automated tests other than those that are specified by the Behaviour Specifications. Developers love writing code, and many love writing automated tests (although contrarily, many do not!). Even when the team together has specified all the required behaviours, some developers can still feel as if they should write more automated tests when they are coding.
If this is the case, it is possible that the developers need to better understand the premise and comparative benefits of Behaviour-Driven Development and also the concept of Equivalence Partitioning.
Benefits Of Behaviour-Driven Development
In previous eras of Test-Driven Development, it was common for developers to write many automated tests for each method within each different class or module. Some of the issues with that approach include:
- A high maintenance cost of automated test assets due to brittle tests that must be refactored when the code is refactored;
- Communication issues between developers and the rest of the team — some developers can find it difficult to effectively describe the automated tests they are coding on a daily basis. This lack of communication can lead to other team members questioning and arguing the value of such activities.
- Developers can struggle to estimate when they will finish all of their automated testing — since the answer is “it depends”, depending on the number of classes and methods written.
- Duplicated testing effort by test analysts — since the automated tests implemented by developers typically are not visible to the non-developers in the team, the testers usually perform many tests that may already be covered by the developer’s automated tests.
In contrast, some of the advantages of the Behaviour-Driven Development approach to implementing tests include:
- The team agrees, up-front, on the behaviours to be implemented and afterwards there is no room for a debate about the value of any of the tests;
- The team decides, up-front, which behaviours are implemented by the developers and which behaviours are performed by the testers — more on this later;
- The team can more accurately provide estimates to management — since the tests are not dependent on the number of classes and methods coded;
- There typically are fewer tests and they are less brittle. When a refactoring of the implementation code takes place, there are less refactorings of the test code to perform. Even though there are less tests, there still can be similar test coverage — because overall behaviour is being tested — not individual method functionality; and
- Test analysts (and everyone) have visibility of all the tests of each component and therefore should not unknowingly duplicate testing effort.