(From Office Blog, Following blog entry took place on January 9th, 2007)
Its been almost 3 weeks since my entry on doing Test Driven Development and we are almost into the middle of the coding phase of the project. I was assigned to doing the Unit Testing for a module that was being developed by a fellow developer.
Initially things started to go fine. But as the code size increased, so did the problems. We had an argument over this yesterday and the TL wanted to keep a sessions in the morning and evening to discuss the problems regarding the unit testing.
- Theoretically speaking, I shouldn’t be writing the unit tests in the first place since I not the one developing the code.
- Unit Tests are to be present before the actual coding is done and not after the coding is done.
- Significant changes in the code were not notified to me, causing me to rewrite about 6 unit tests for a class. Finally yesterday after the argument, he sent me mail when there was a change. The letter had the subject “The code has changes and is updated in VSS” and no body for the letter. How am I exactly supposed to know What is changed? and Why is it changed?
- Changes in the Folder Names / Structure were not notified causing some Unit Tests that were running successfully to fail
- Problems that occur in Unit Tests should be notified then and there as this is what the developer is expected to do, if the unit testing was done by the developer.
- Out of all the problems that I faced, the biggest was of course lack of “Why” Comments in the codes. Majority of the code had no and very less comments especially when it came to explaining the logic behind the code.
The biggest challenge in writing Unit Tests especially for some one else is to understand the code / logic behind the code, which isn’t such an easy task. I don’t know to how much extend the exact philosophy of Test Driven Development Philosophy is followed in Cognizant but in my project the “Golden Rule of TDD” was never followed, “Never write a piece of code until you have a test for it”, since I was writing the Test Scripts well after coding the logic, its very hard to expect the “Assertions” just by reading lines and lines of uncommented code. I asked him politely to comment the code so that I can easily decipher the code but he said you ask me anything and I will tell you.
Everything began falling apart whenever something unexpected arises from the Unit Testing and I used to go and ask him whether this is expected or not (as I said before the code is absolutely uncommented), so I used to go with a vague I idea and discuss, as the frequency of this became too much, it became annoying for him which eventually led the unit test discussions being split up into sessions in morning and evening, because regular clarifications were disturbing his developmental flow it seems.
Now from a unit tester’s perspective, if I don’t clarify the problems then and there it could hamper me from writing other unit tests that have a dependency for that Unit Tests or even worse other classes that are depended on this class and it disturbs my logical thinking for unit tests as it is strongly coupled to the code written by the developer. For me reading uncommented code especially when written by others is very tough, for example if you were to read about 100s of lines of code with not “Why” Comments for the IFs and ELSEs out there. This is one of the guidelines set in the Coding Standards by Cognizant, which is not at all followed here. Another thing I that went absolutely out of the way was the lack of communication of significant changes in the code, that affected the unit tests and code coverage drastically.
Finally when the developer does frantic coding, and is held up with Design Documents etc its not an excuse to say “I haven’t written comments for the code and unit tests because I know my code works”, that statement may be a self satisfactory explanation to one’s self, but its rather annoying to the other person reading the code, undisciplined and breaking the very spirit of TDD.
Lets see How the phase progresses and the Unit Testing goes. And above all this we have to do integration tests which are depended on the Success of the Unit Tests written here. Will keep you guys updated on the status.
