I always long to write here frequently, but still unsuccessful and without excuse. So, here is the next entry.
We already discussed the topic “Test Driven Development” : Writing and executing test case before adding/modifying the existing functionality.
To understand it better, Let us think of a scenario where a product “P” version 1.0 need some enhancement in the existing functionality (say an image editing software supporting .bmp and .jpg format, requires an enhancement as .png format support). Test cases to verify the functionality for product “P 1.0″ are written.
In the process of adding any new functionality, some existing functionalities breaks (say in the above example, jpg support not working).
These question starts popping in our mind. What went wrong ? How to proceed? What can be done as a safeguard for next time ? blah blah blah…
1> If this is a new functionality issue : “Pop your collar”. Test Harness is fine. So, according to the “Test Driven development cycle”. write code for this new behavior, so that this will pass.
2> If this is an old functionality issue : Proceed in this sequence,
a> Code coverage :
2.a.1 : statement coverage : find the statement which is not covered by the test cases.
2.a.1 : branch coverage : find the branch in code which is not covered by the test cases.
2.a.1 : path coverage : find the path in code which is not covered by the test cases.
if you find anything here, write test cases for these and try to catch the issue by executing it. else goto next step,
b> Memory leak.
We already have lots of utilities available to find out memory leak in a program.
If you do not want to use them, i suggest write your own memory tracker…believe me its not so tough, if you have complete access of code and you can compile and run it easily.
how ?
Steps are :
1> Add your own memory allocation counter at location “new or malloc function implementation”.
2> Similarly, decrement your counter at delete() or free() implementation.
Find out the atomic blocks. : I define atomic block as,
Lets “S1″ be the current state of the memory, and “S2″ is the state of memory after executing a piece of code “X”, such that S1=S2 then, X is an atomic block.
So, find out different atomic blocks of the product. for example, i added one item and deleted the same item, in most cases , this whole code of addition + deletion , can be treated as atomic block.
One these atomic blocks are decided, execute it one by one and put the alert by validating the counter.
Performance : Performance can always be major hurdle in product development. Here also these atomic blocks would help you better. Execute these atomic blocks both in previous version and current version of the product and draw an acceptability graph.
Here i stop hope you permit. Will elaborate more on these above points individually as separate posts.
