Skip to Content

Changes for page Test-Driven Development

Last modified by chrisby on 2024/08/27 08:42
From version 1.23
edited by chrisby
on 2023/11/30 18:40
Change comment: There is no comment for this version
To version 1.26
edited by chrisby
on 2023/12/08 07:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -16,12 +16,13 @@
16 16  
17 17  **Remarks**
18 18  
19 -* **Not compiling is a failure**: For example, if the test code requires a function from the production code that has not yet been defined, compilation will fail.
19 +* **Not compiling is a failure**: For example, if the test code requires a function from the production code that has not yet been defined, compilation will fail. Since the test fails, you must next go to the production code and make the test pass.
20 20  * **Workflow**: In practice, you start writing a test until it fails, then switch to production until it passes, switch back to test code until it fails, and so on until the feature is complete. This leads to a very fast oscillation of switching between test code and production code. The last test should have passed within the last few minutes.
21 21  * **Debugging**: The very short TDD cycles result in far fewer bugs. Bugs may still occur, but they are often trivial and don't require debugging. Experienced developers are capable of debugging, but they do not spend much time on it because of the consistent use of TDD.
22 +* **The tests need to run fast** so as not to block the developer from doing his task. See this [[test execution speed enhancing article|doc:Software Engineering.Testing.Enhance Test Execution Speed.WebHome]].
22 22  
23 23  ### Code Coverage
24 24  
25 25  * **Incomplete Validation**: Passing tests doesn't mean that everything works, just that the tested parts aren't broken. Code coverage is a good first indicator of whether there are enough tests.
26 26  * **Almost 100% Code Coverage**: Code coverage needs to be high, ideally 100%, but in reality the practical achievable is in the high 90s. But code coverage alone is no guarantee of useful tests, so it should be taken with a grain of salt. It is better to look at the tests to get an idea of the actual quality of the test suite.
27 -* **Team Metric**: TDD is a technical agile practice, and therefore code coverage is a metric for developers to make decisions about, not the business.
28 +* **Technical Metric**: TDD is a technical agile practice, and therefore code coverage is a metric for developers to make decisions about, not the business.