How Unit test have been useful for me

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 other blogs 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.


Java or: How I learned to stop worrying and love the code

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-Martin Fowler

In college I learn Java, I like the idea of « code once , run everywhere ». After college when I start to program in Java some personal project, I knew that my code was awful / smelly. Bad design, not optimize, near zero comments, and with a lot of duplicate code. My first thought was who care, nobody else will see my code. One big problem, my code base start to grow larger and larger, so a lot of time, I screw up my own productivity because bad design.

I started to look online to learn good practice, started to code in respect Sun Java convention (about indentation, method/class naming, etc). I did a lot of refactoring, creating new class, to improving general quality of my code. But at that time I was not yet fully proud of my code. In some open-source API ( like Trident and ICTK), the code is very clear, it wasn’t always the case in my code.

Nobody can write a « perfect » code, but all programmers can at least try to write better code. In enterprise environment, a good way to increase code quality can be done with code review session and with pair programming. In a solo programming environment like I do for SuicideChess project is quite more difficult.

How to increase code quality in a solo project?

Here, few idea:
First, release your code as open-source, even if nobody look at your code, knowing that people can do it, you’ll try write better code.

Second, be sure that your code contain any error or warning message.

Third, find some tools to help you. I’m using Eclipse to develop all java code of SuicideChess. With Eclipse ( and probably most of IDE ), you can add plug-in. Some plug-in can give you a direct feedback on your code quality. Just to name few that I use : FindBug , Eclipse Metric and UCDetector.

Fourth, read a lot about it. There’s many website about best-practice , design, etc.

To push this even farther, I will release soon, a web-page to see the progress, on monthly base. Why may you ask? Because when you solo-program, sometimes it’s hard to motivate itself, so by publishing these kind of info, I’ll be able to see progress over time.

In computer science, you can always learn new things, and there’s always some limit to break. So let’s go push farther !
When I start the opening book , my first goal was to create a good opening book for nessegrev. I was dreaming about the day that the opening book will reach the size of the nilatac’s one. Now I look at it, and I said : » wow in February, the opening book will be 10 time bigger than nilatac’s one ».

Few month ago, I read a good article : Party of one: Surviving the solo open source project. This article was the reason I started this blog.

when I started to code SuicideChess project, I didn’t have a lot of experience, so I code a lot before think about design. Adding new features was fun, so at the time, I was push debugging time to later. Humm.. a very bad idea. That’s why recently (since about 2 month) I start to refactoring my code, debug, rename Methods/Class, etc. With all those refactoring, the number of line of code (LOC) start to drop. This can seem stranger for new programmer, but senior programmer know this: Less LOC = less bug. To quote Richard Pattis:
« When debugging, novices insert corrective code; experts remove defective code. »

That explain why you see less new features recently, even I still work a lot on this project. I know that I still have a lot to do, but working with a better code will make my life easier

I’m not a java expert, at least I don’t think so, when I compare myself to others Java Blogger like ( Kirillcool and Jonathan Giles). I wish I could blog like them, but I know that new programmer still need a lot, because in school, they never learn know about code quality, debug, etc.
Telling them my experience, I hope that they’ll learn something.

I most tell that one of the hardest part of solo-programming a project is to have enough motivation. Just a quick look on Sourceforge or on Kenai, you’ll see a lot of abandoned (dead) project. That’s kind of sad, because many of them are great idea. There’s many things that will de-motivated any solo-programmer: Lack of user feedback, debugging to do, lack of time, and a lot of learning to do. If you can manage those facts, and still able to continue your project: good and go ahead!

Programming is a art, maybe a technical art, but you must like your code! My code isn’t perfect but I love it