Difference between revisions of "SoftReferences for Traceability"
| Line 8: | Line 8: | ||
<youtube>EZ05e7EMOLM</youtube> | <youtube>EZ05e7EMOLM</youtube> | ||
One of the arguments was that test code was extra code and needed modification far too often even if the requirements had not changed. | One of the arguments was that test code was extra code and needed modification far too often even if the requirements had not changed. | ||
| + | [[Category:frontend]] | ||
Revision as of 09:48, 18 October 2018
| BlogEntry | |
|---|---|
 edit
| |
| date | 2018/10/18 |
| title | SoftReferences for Traceability |
| author | Wolfgang Fahl |
This morning I was developing a JUnit Testcase for a current project. I found it very rewarding and useful to do this work. One step in the process was to apply "design for testability". I had to test a piece of code that was some 30 lines long and part of another function that was already some 60 lines long. In the process the 30 lines became another independent function. This has the effect to make it testable independently and also cleaning up the code since now both functions where only half a page long which makes the code much more readable. Also things get reusable this way. I could keep going on an arguing in favor of test driven development and design for testability. What struck me this morning was that I remembered a presentation "TDD where did all go wrong" in which Ian Cooper told the story of TDD projects that were not going well (enough) and why in recent projects he as seen a lot less TDD. One of the arguments was that test code was extra code and needed modification far too often even if the requirements had not changed.