Don’t try to suicide : succeed!!

Menu

Archives de Tag: tool

In college, I learn nothing about Unit test. JUnit was just a strange IDE feature for me. Few years later, I started read about it. My first thought about unit test was that will be usefulness for me, since I was working only on a personal project, not in enterprise. I didn’t want to add complexity and developing time to my project.

Last year, while optimizing some part of my code, I did a little mistake : I forgot a single ‘!’. Oops. This new bug wasn’t a big one, but occur a spare time. It took me a day of debugging to finally find it.

A day lost just by a single mistake…

The day after, I decided to start learning about Unit test. I chose to use TestNG over JUnit, simply because it seem to be easier to use. I’m not a expert about this so I let otherblogs to debate about it.

In conjuncture with unit test, I start to use a code coverage plug-in, the Eclemma. The purpose is to know what part of my code is covered by unit test. Now I know some advantage of TDD, but since my project way before I learn all this , only some part of my code is covered. I’m still working to increase the coverage each time I code. Before refactoring any part of my code, now I prefer to add some unit test. This way it reduce my chance to introduce new bug. It’s just a safety net, not a bullet-proof , I still need to concentrate.

Unit testing and code coverage, is probably more useful in a team project, to be sure that you didn’t broke anything of others developers. I believe that in a open-source project is a good idea, to give people a safety net if they want to modify the code.

Another important point about unit testing, is that it most be run every time at some code is added or modify. If not, when you’ll run it, I find that you broke something, it’ll be hard to find where you had added a bug. There’s several way to do it: by hand or with a continuous integration server. The main advantage of doing it by hand is that you don’t need to setup a continuous integration server, so it could be a good way for a solo developer. With a continuous integration server, unit test can be done automatically, so you don’t need to remember to run these unit tests but you need to setup the server. When a developers team grow, a continuous integration server, is the best way, since you can’t be sure that all developers have run these tests.

I still don’t know what is the best way to do it, but at least it work for me. On the long run, unit test take a little more time at start, but you will save a lot of time later.
Some people claim that you need a 100% code coverage, some don’t. Like any flamewar, read about it, and find what is the best for you and your project.

For any new developer who want to learn some new skill, I suggest to read this blog post. I discover this recently, I wish to found it way before, like when I was in college.