Difference between revisions of "SoftReferences for Traceability"
| Line 6: | Line 6: | ||
}} | }} | ||
{{SimpleArticle|title=SoftReferences for Traceability|text= | {{SimpleArticle|title=SoftReferences for Traceability|text= | ||
| − | 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 | + | 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 has seen a lot less TDD. |
<youtube>EZ05e7EMOLM</youtube> | <youtube>EZ05e7EMOLM</youtube> | ||
Revision as of 11:05, 18 October 2018
| BlogEntry | |
|---|---|
 edit
| |
| date | 2018/10/18 |
| title | SoftReferences for Traceability |
| author | Wolfgang Fahl |
SoftReferences for Traceability
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 has 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 or only slightly changed. It seems to me that this dicussion leads to the question of the value of the three items
- requirement
- code
- testcode
Quite a bit of the arguments in software engineering seem to revolve around the question "What is more valuable?". Some will answer that code is the only result you need and keeping track of the requirements and writing test code is just Muda or "enterprisy cruft".
You'll find a lot of other positions e.g. the one that I am going to take to today that are based on the traceability triangle of the three items shown as a graph below:
