If it compiles, it is unit tested!

Posted in blog city on May 7th 2004 

A recent blog by Sam Pullara details an innovative mechanism of test coverage. Using AOP to get the list of test cases for a given method seems to be a really coool use of latest technology. However, I do believe there must have been products that offer this functionality of listing test cases covering a given method already built into them using different means.

Integrating this with IDEs like Eclipse so that appropriate tests are automatically run as and when a method is modified, seems to be a killer idea. But not sure how many will really be able to use this feature in IDEs primarily because to do a test coverage, one needs to have test cases 😉

In my little experience in this industry,

 — Majority of the software projects rarely have a “well defined” unit test cases. Developers like me just skip “unit testing” phase citing it as boring and more importantly have other exciting things (such as blogging, chatting, browsing) to do!

— Even with frameworks such as JUnit, which promise unit testing to be fun, developers have not really started unit testing. Many of the developers still strongly believe that “as long as it compiles, it is unit tested!”. Developers love the challenges that come up when the code does not work as expected at the time of integration. Else, software development will just be damn boring!

— And for very few projects that have well defined unit test cases (in Junit), they love to run all the test cases as many times as possible, since not only it does not cost them any thing to run the same test cases multiple times, it also provides additional sense of satisfaction/achievement for having developed so many test cases. Even if the change is to a single method, they would love to run all the test cases “just to be sure” that the change did not break something else!

Overall, there is no need for IDE communities to slog and implement this killer feature described by Sam Pullara as there will be very few people who will rely on that to conduct thier regression testing. 

Comments

#1

‘‘ posted this on Fri 7 May 2004, 6:47 pm Its true, that developers do not write test cases and the reasons are too obvious. 1) Personal aspect – Too boring 2)Confidence – My code WILL run 3) Oversight – I can’t see any reason why someone would change this code in future.Having said that, I see developers getting used to unit test cases. Some by their own free will, some due to pressure from some “Pointy haired boss”. Someone would have put this unit test cases stuff into his head. So atleast to look fasionable, the boss insists on Unit test cases. murali

#2

‘‘ posted this on Mon 17 May 2004, 10:53 pm It seems to me the usual reason that developers site for not writing unit tests is schedule pressure. (no time!) Not because of a overabundance of confidence in their code or that they find unit testing boring.Pete McKinstry [pete_mckinstry@yahoo.com]

Unit Testing – Necessary but not Sufficient

Posted in blog city on July 12th 2004 

Mike Spille wrote his opinions on unit testing and JUnit in his recent blogs. Read some of them here and here. As is the case with any post, there are many points I agree and quite a few that I disagree. As a disclaimer, I am not a die hard follower of XP/TDD as I believe they are just some common sense ideas documented in detail.

JUnit has certainly changed the way developers look at unit testing. At the least, it has made unit testing poplular. Yes, it will not solve all other problems of integration testing, performance testing, MT testing etc. — but still it does help in unit testing.

As I see this is very important. Unit Testing is an necessary but not sufficient testing for any useful peice of software. We cannot think of next level of testing without unit testing. And when you have a complex project where multiple developers across geographies are involved, it becomes all more important to have unit test cases that follow some kind of framework, which is where JUnit fits in, rather neatly.