Tuesday, September 30, 2008

Testing Experience with Emma and JUnit

Objective

To become get familiar with testing tools such as Emma and JUnit. Also fix the Stack project so that the Stack project has 100% of coverage.

Improve Coverage

Emma is powerful tool that shows how many percentage of the original source code tested for expected output. Even the Stack project has fixed in order to pass the CheckStyle, FindBugs, JUnit and PMD tools, it had only 73% of coverage for method, 69% of coverage for block, and 75% of coverage for line on EMMA Coverage Report. In order to improve coverage on the source code, users can click the link for each class and Emma shows uncovered parts in red block. All fixed source file can be downloaded from http://www2.hawaii.edu/~jeho/ICS413/stack-jeho-6.0.930.zip

Added Test Cases
For testing toString method in the Stack class returns expected output:

assertEquals("Testing stack toString", "[Stack [1, 2, 3]]",stack.toString());
For testing EmptyStackException method in the Stack class returns expected output:

@Test(expected = EmptyStackException.class)
public void testIllegalTop() throws EmptyStackException {
Stack stack = new Stack();
stack.top();
fail("Top of empty stack did not generate exception.");
}
For testing isEmpty in the ClearStack class returns expected boolean return value:

assertSame("Testing for isEmpty",true, stack.isEmpty());
assertSame("Testing for isEmpty when it is not empty", false, stack.isEmpty());
For testing getTop throws EmptyStackException:

@Test(expected = EmptyStackException.class)
public void testIllegalgetTop() throws EmptyStackException {
ClearStack stack = new ClearStack();
stack.getTop();
fail("Top of empty stack did not generate exception.");
}
Reflect on Coverage

Emma is very useful tool because it automatically produce a report that shows which method or block need to be tested. The report was well organized and easy to understand. I believe improving the coverage of the original Stack project to 100% actually improved the quality of the system because I had to write additional test cases, which is actually needed to improve the quality of the system. I had little problem that the eclipse did not recognize other classes when I tried to change code with eclipse. This problem solved by clicking project - clean button and change the Java Build Path from /build/ to /bin/ .

Wednesday, September 24, 2008

Automated QA vs. Manual QA

Objective
Compare the results of Checkstyle, PMD and FindBugs to the Manual QA that is written by a classmate on the CodeRuler Project.

Automated QA vs. Manual QA
I got 644 errors with Checkstyle tools on my CodeRuler Project. Most of Errors occured because the original source files contain tap characters, which is not supposed to use when we coding. There were also few errors for the documantation because I did not make few comments for the Javadoc. I also did not used {}s for if statements and Checkstyle reported errors on this, too. PMD tools also reported on the same problem of my code that I did not used curly braces for if statements. On the other hands, there were no erros reported with FindBugs QA target.
I learned that I had many problems with correct coding style from Manual QA, too.

Conclusion
Automated QA is good for reporting more specific and detail information about the errors that the source code has, however, it takes time to write and edit ".xml" files for build and other tools. On the other hand, Manual QA is good for checking the flow of the logic in the source program. In conclusion, I believe we can always use both Automated QA and Manual QA for better programming.

Experience with Ant - Stack

Objective
  • The Ant build system
  • Open source Java automated quality assurance tools (FindBugs, Checkstyle, PMD)
  • The course standards for build system structure and packaging.

  • This assignment was my firs time to using ant to build a system. I have some experience with Make build tool for other classes, which was pretty difficult to use. During the studying for Ant, I learned that I can download and use open source Java automated quality assurance tools(QA tools) such as FindBugs, Checkstyle, PMD, and etc. Each automated QA tools have own purpose and tasks to the source files and these functions are very useful when we build a system.

    Installation
    In order to use Ant build tools with JUnit, PMD, FindBugs, Checkstyle, and Emma, we need to download each QA tools from sourceforge.net. Since the Ant tools does not like spaces in the directory name, is is recommended to unzip into a directory without spaces. After the unzip all files into correct directory, it requires users to define environmental variables for each QA tools. It took about 2 hours for me to make all environmental variables and classpath works correctly. After set up all installation and environmental, finally we can try to run ant build system with stack project. The given targets was following

  • ant clean compile
  • ant -f checkstyle.build.xml
  • ant -f dist.build.xml
  • ant -f findbugs.build.xml
  • ant -f javadoc.build.xml
  • ant -f junit.build.xml
  • ant -f pmd.build.xml
  • ant -f verify.build.xml

  • All of targets above was successful but the verify target was fail because the example provided contains few warnings with Checkstyle, JUnit, PMD, and FindBugs.

    Using Stack as a Template to create a new Project
    Create my own project from the provided example was pretty much straight forwarded and I did not encountered any problem during this step. The most important part of this step was that I edited the system.name property from "stack" to "stack-jeho" in the build.xml file.

    Fixing the problems in Stack so that "verify" target passes the build
    When I ran each QA tools for the stack project, it produced automated directories and report html files. All report html files were well organized and easy to read. It also displays the errors or warnings with correct source names and line number in the source file. To fix the problems that the original source has pretty easy. The most difficult part to fix was that fix the TestStack.java that has empty catch block because I did not know how to write a test that passes when an expected exception is thrown. After fixing all the problems reported by Checkstyle, JUnit, PMD, and FindBugs, I ran "ant -f verify.build.xml", which create a distribution zip file in the build directory. This file can be downloaded from here.

    Monday, September 15, 2008

    Code Review - Code Ruler

    Purpose
    To identifying violations of Java coding and documentation standards.
    To look at how the code perform the task in efficient and effective manner.

    Reviewed code - Mari-Lee Flestado

    FileLinesViolationComments
    MyRuler.java1ICS-SE-Java-2Used wildcards"*" in import statements.
    MyRuler.java95EJS-5Code has wrong indent for "}"
    MyRuler.java12,13,14,*EJS-8Used "hard" tabs.
    MyRuler.java109, 119EJS-9Did not use meaningful name
    MyRuler.java91EJS-61Used end-line Comment


    Summary
    The entire documentation was understandable enough, except some missing JavaDocs for class and methods. During the excution of the CodeRuler, it constantly throws ArrayIndexOutOfBoundsException when the ruler has no castles. This is because the code tries to command to a castles which is not exists. Her strategy for peasants was same as mine which find a random direction for the next move and this works fine in the competition. Her strategy for knights has a small logical error that all knights actually try to only attack enemy's castles which she was not intended to. This is because there are three commands to each knight in one turn. Therefore, the program always try to run the last command to the knights which attack the enemies' castle. Overall, other than the issues with some logical errors, the code was readable and easy to understand.

    Link to Mari-Lee Flestado's code
    http://www2.hawaii.edu/~flestado/marilee.zip

    Link to Mari-Lee Flestado's Blog
    http://mari-leeflestado.blogspot.com/

    Monday, September 8, 2008

    Lessons learned from Code Ruler

    Overview

    CordRuler is Java based programming game based on Eclipse IDE. CordRuler designed for competition of student programers between universities. Each participants need to implement MyRuler.java which controls all personal Knights, Peasants, and Castles that the Ruler has. Knights can kill enemy's Knight or Peasants, or take enemy's Castle. Peasants can take a land by moving to that position. Castles can produce Knights or Peasants depends on the amount of the land.

    Results


    VS Migrate RulerVs Gang Up RulerVS Split Up Ruler
    First Try502 : 45536 : 57552 : 56
    Second Try534 : 45503 : 76314 : 63
    Third Try543 : 42548 : 70532 : 104

    Stratege

    Knights

    When indivisual Knight's strength is below 30:
    The Knight try to attack enemy's Peasant or Castle.

    When indivisual Knight's strength is over 30;
    The Knight try to attack enemy's Knight.

    Peasants


    Randomly move to other points.

    Castles


    Produce Knights when the number of Knights are insufficient.
    Produce Peasants when the number of Peasants are insufficient.

    My Source


    Source Download

    Monday, September 1, 2008

    Open Source Systems Experience

    Overview

    Sweet Home 3D is an Java-based open source system for interior design which helps quickly choosing and placing furniture on a house 2D plan drawn by the end-user, with a final 3d preview. Sweet Home 3D executable version can be downloaded at http://sourceforge.net/project/platformdownload.php?group_id=152568. We can also download source files by clicking http://downloads.sourceforge.net/sweethome3d/SweetHome3D-1.3.1-src.zip?modtime=1219874511&big_mirror=0&filesize=14746696.

    Prime Directive 1 - The system successfully accomplishes a useful task.

    Sweet Home 3D does accomplish a useful task which is 3D Modeling. When users need to redecorate their apartment or rearrange the existing furniture, Sweet Home 3D helps a lot. This program provides 75 furniture models that users can place in the virtual room. Also all furniture represented by a small picture and are categorized according to their placement in the real house. I tried to rearrange my living room on this program and I could found all furniture that I have in the category named "Living room". First, I tried to set all furniture in the two dimensional windows and the program correctly shown three dimensional images. After this step, I could rearrange furniture on the two-dimensional windows and three dimensional windows changed as well.


    Prime Directive 2 - An external user can successfully install and use the system.

    I downloaded Sweet Home 3D and tried to install it on the Windows XP Professional. According to the program description, it supports 32-bits Windows, Linux, and OS X. The installation of Sweet Home 3D was fast and smooth. It was just same as other formal program installation.


    Prime Directive 3 - An external developer can successfully understand and enhance the system.

    I could download Sweet Home source files from http://downloads.sourceforge.net/sweethome3d/SweetHome3D-1.3.1-src.zip?modtime=1219874511&big_mirror=0&filesize=14746696. The zip file contains README.TXT file which includes how to use the source code and how to compile using Eclipse project or with Ant. All source code classes are compatible with Java SE 5, and the directory contains all the information required to compile. Therefore, Prime Directive 3 is satisfied.