Blogs - ractoc123

I'm really starting to have second thoughts about this whole QA thing I've set up. I know I need it, and I will off course keep going with it. But since I've first coded a very big chunk of code, even making Alpha 1 stage, before setting up QA, I have a lot of work to catch up.

I've been writing up unit tests for a week now, and I'm not even half way through. Even while writing them however, I have found a number of areas which could use some improvement. So in that regard, it has already paid off.

Once I reach the point where my unit tests have caught up with the rest of the code base, it should become easier to manage. Since then, each change in the codebase will have a limited amount of new or changed unit tests linked to it. Hopefuly. Ah well, we will see.

After talking to some friends and fellow developers, I've decided to do the whole QA thing in the form of tutorials. As such, they will also be made available through the tutorials section. You can find the first one here: Indiedb.com.

Well, the last few days have been interesting. After getting my game ready for the first closed Alpha (invitation only), I decided to setup some Quality Assurance.
I'm building this thing in Java using JME (JMonkeyEngine). This means I'm using Ant. As such, I ended up adding all the QA through Ant as well. I've set up 4 different types of QA tool:

1. Checkstyle
2. JUnit
3. Cobertura
4. findBugs

In order, these do the following:

Checkstyle:
This is a tool which lets me setup a coding standard, and enforces it. When I now run a full test through Ant, it also does a full check of all my source code against the coding standard I setup in Checkstyle. Any errors found are then logged in a report document.

JUnit:
JUnit is a tool for performing automated unit tests in Java. This means I can write testcases for each of my Java classes and then run these from Ant with the JUnit Ant task.
The results of the tests are stored in report files.

Cobertura:
Cobertura is a tool which complements the JUnit tool. It detects how much of the code is actually covered by the JUnit tests. It does this pretty thoroughly. Not only does it detect if a certain line of code is hit by the tests, it also detects if all the various branches of the statement are covered. What this means is that, for instance, a simple IF statement has two branches, which both have to be tested for cobertura to flag that IF statement as covered.
The result of the Cobertura tool are stored in a comprehensive report.

findBugs:
This is a tool which only runs partially inside Ant. It also needs parts which are installed outside of Ant. While this means more complexity added to the build, the tool offers a QA advantage which makes this worth it.
It tests the code for known performance problems, bad practices and much more. Not everything it comes up with is an actual problem though, sometimes a problem found by findBugs is actually the only way to do something. But overall, it does come up with better solutions more often then not.

In following Blogs I will try and explain more about these various tools and how they can improve your Java code quality. But let me and with saying that, if you do decide to add QA you had better do it early in your development process. As it stands, I added it later in the process and now I'll be spending the next few weeks doing nothing more then fixing QA issues. When you are doing the QA tests from the start, the stuff you find is easily fixed.
For me, I find I have to occasionally do some heavy rewriting just to fix a QA defect.