Difference between revisions of "SoftReferences for Traceability"

From BITPlan Wiki
Jump to navigation Jump to search
(Created page with "{{BlogEntry |date=2018/10/18 |title=SoftReferences for Traceability |author=Wolfgang Fahl |storemode=property }} This morning I was developing a JUnit Testcase for a current p...")
 
Line 5: Line 5:
 
|storemode=property
 
|storemode=property
 
}}
 
}}
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 function with 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 where
+
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 where

Revision as of 10:42, 18 October 2018

BlogEntry
edit
date  2018/10/18
title  SoftReferences for Traceability
author  Wolfgang Fahl
pdf  

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 where