Using Ant/QA Tools to Build a Robust Program Package

As programmers there are many tools out there that streamline the writing process and optimize code. Some tools create all in one programming environments to work in (IDE's), some tools help you to build projects, and others do all sort of cool things that clean-up and optimize code. Previous to taking ICS413 I was never exposed to these technologies (apart from IDE's). I never knew the power these sorts of things hold in a programming environment. 

TASK 1

The main goals of this exercise were to 1) become familiar with the ANT build system, 2) become familiar with Open Source Java automated quality assurance tools, and 3) learn more about the build system and packaging standards for our ICS413 class. The first task was to simply download and install the specified Java tools on our system:

• Checkstyle 5 Beta - checks source code mainly for layout issues based on a coding standard.
• PMD 4.2.3 - Checks source code for things like bugs, dead code, overcomplicated expressions, etc.
• JUnit 4.5 - A framework for writing and running automated tests.
• FindBugs 1.3.5 - Uses static analysis of byte code to look for possible bugs.
• Ant 1.7.1 - A Java based build tool. 'Make, but without Makes wrinkles'

In addition we were to download the source stack package to test these tools on. It turns out that this task was one of the more challenging parts of the assignment. After I downloaded each tool, I had to go and edit some environment variables on my machine so they would point to the respective tool. Since I use a mac I had to edit my .profile file to add some environment variables like this:

export ANT_HOME="/Users/tylerwolff/Documents/ICS/Tools/apache-ant-1.7.1"
export CHECKSTYLE_HOME="/Users/tylerwolff/Documents/ICS/Tools/checkstyle-5.0-be$
export FINDBUGS_HOME="/Users/tylerwolff/Documents/ICS/Tools/findbugs-1.3.5"
export JUNIT_HOME="/Users/tylerwolff/Documents/ICS/Tools/junit4.5"
export PMD_HOME="/Users/tylerwolff/Documents/ICS/Tools/pmd-4.2.3"

Luckily a friend in class helped me get to this point. Otherwise I would have been at a loss at what to do. I also needed to change the path to ANT 1.7.1. After I finally managed to finish this all, I ran some tests to see if I had installed everything correctly and it worked just right.

TASK 2

The default stack project was already set up with all the xml files needed for the ANT build system. All I had to do was go in and rename some of the variables to add my name to the project . The most complicated thing I had to do in copying the project was to go into the verify.build.xml file to remove the statements referring to the 'emma' tool which is not in use yet. I found the ANT xml files to be extremely easy to understand and decode. Its almost like an upgraded MAKE system. I guess thats why they themselves call it 'Make, but without Make's wrinkles.'

TASK 3

After copying the project, I worked on and finished fixing the problems associated with it during class, with the help of Daniel Arakaki. We used each tool, found the bugs or errors associated with the project, and continued on to fix the problems within the source code. All in all, I have to say it was a very streamlined process using the QA tools. They run instantaneously to produce a very readable page of errors. Although I was not surprised to see errors arise after invoking each tool, I was surprised at how easy it was to understand what the errors actually were. Many of the tools, like PMD and FindBugs even go a step further by linking the errors to full descriptions with examples. This made it really easy to fix some of the errors. For instance in the Stack.java file PMD suggested that instead of using implementation types like ArrayList, use an interface. I was a bit confused by this at first so I clicked the error link and it gave me a concrete example of what they mean and how to implement it. It's a great system!

The rest of the errors were checked and now the project verifies perfectly.

Finalized stack system: stack-tylerwolff-6.0.923.zip 

Overall I feel comfortable using these programming tools now. I don't think I will program anything from now on without them. ANT especially makes it really easy to compile and build entire systems. I like how you can use it to invoke quality assurance tools as well. Its so easy to go through and use these automated tools to better your program. I really think its a good thing to do. I love that fact that you can even learn from using these tools as they show you new errors and changes to make to them.

Thoughts on Automated vs. Manual Quality Assurance

When programming it is always hard to get the code looking and working right the first time around. More often than not, we miss the littlest, most minute details in our program code and it fails because of it. Those are the times when it is ultimately useful to get an objective, outside view of your code. 

In addition to having another programmer look and check for errors in your code, there are many automated tools that scan your code for possible errors. Some of these tools like Checkstyle and PMD scan your source code for things like formatting and code efficiency errors. Other tools like FindBugs scan actual byte code for bugs. Using these sort of tools can make your code optimal and up to standard. But how do they compare to actual human quality assurance checks?

I ran Checkstyle, PMD, and FindBugs on my CodeRuler solution to see what sort of errors were found, and compared these results to what two of my other classmates found in my code. Here's what the automated tools found:

• Checkstyle : 24 errors in MyRuler.java (67 errors total including IBM classes)

1.         20 errors due to lines over 100 characters long
   
2.         3 Javadoc errors
   
3.         1 error due to using a import wildcard statement '*'
   

• PMD: 10 errors in MyRuler.java (36 errors total including IBM classes)

1.         All priority 3 errors with code suggestions
   

• FindBugs: 0 errors in MyRuler.java

As this was my first time using these automated tools I was surprised at how easy and simple they are to use. Instantaneously errors are found and presented in an extremely efficient way. Checkstyle proved to find many formatting errors and described them all well. With PMD I was surprised to find that they not only show the errors but links to full descriptions with examples. How great is that! FindBugs found no errors but I'm sure if the code was more substantial and complicated it would have.

CONCLUSION

Compared to Manual QA checks, I think the automated tools did an amazing job (at least with my CodeRuler classes). When Arthur Shum and Aric West did a check on my code they found many of the same problems - wildcard import statement, long lines of code, javadoc problems, etc. However, what they were able to find were more complex formatting problems such as redundant inline-comments, confusing code segments, and bracket placement. A lot of these problems would essentially make the code even more readable and Checkstyle did not find them. I think a Manual QA check is essential if your code needs to adhere to very specific standards. 

PMD found some errors that I think would take another programmer awhile to point out, especially with long code. It is possible that a programmer could find all these same errors. However, PMD finds them instantly and presents them so well. I actually learned a thing or two from looking at the errors in my code. The errors gave great suggestions into making the code more efficient and readable. 

Overall, what I think makes Automated QA so great is that is instant. These tools can be acquired and used in a matter of minutes. What's more is that using them can even teach you new tricks. If there are still problems in your code, such as logical errors, then manual checks can be done. From what I've seen by doing this, using a combination of both automated and manual quality assurance checks can make your code optimum.