16.MyIsernReview

1. Installation Review

I was able to download the program successfully from their code.google.com website with no problems. I also able to run the system using without using ant (using java -jar method) and was pleasantly surprised to see an actual window pop up with all the information in a neat table instead of the usual print out to dos. That was a very nice touch. It made things a lot easier to see and made it look very professional. After I ran the ant verify task and found that the coverage wasn't at 100% but aside from that all the other tasks went through fine and verify passed. After taking a look at the code, I found that the only reason EMMA wasn't at 100% was because of a catch statement in case something went wrong. Since was only had the file that we were given and here are no errors there, I don't expect the coverage not being at 100% a problem.

2. Code Format and Conventions Review

For once, I could not spot any code format or conventions violations. I actually spent the time to go through the Elements of Java Style book and looked for each format violation and couldn't find anything. Good job!

3. Test Case Review

Since this a simple application that just takes data from xml files and then converts them to Java usable files that can e displayed easily in a window there really isn't much to break. Hence, there was no other option that I could use to bring up the table other than actually calling it. As for black box testing, the same can pretty much be said. There isn't much that can be done for testing. The data comes from an xml file and is converted into something that can be used in Java. So as long as the data in the xml file matches the data that comes up on screen and runs then pretty all tests will pass. All the tests included follow along this line of thought. If any part of the program fails, an equivalent test fails as well.

As for white box testing, Phil's coverage is at 99% which might actually be better than 100% because his code include a catch statement that really can't be tested but will notify users of an error if anything does happen to go wrong.

As for breaking the code, since no arguments are passed when the program is called, anything written after the java -jar *.jar command is effectively ignored which is good and bad because it won't crash the program but the user doesn’t know that anything included in the call isn't used at all.

4. Summery

Phil has really gone above and beyond for this assignment. Where I just made sure the jar file was created and run an output the screen, Phil made a GUI that displays the information in a nice table. This program was a bit hard to test for because it was really hard to create a test for something that just prints information to the screen. Off the top of my head, I can only think of testing that the data is right during each step it is being converted. But at the same time, just looking at the output in general is about the same thing. If there is an error usually the error is apparent in the output, i.e. getting a block address instead of a name. I know that I didn't really put many tests other than just making sure the output was sent to the screen. But Phil actually has a few lines that test whether a few of the steps along the way also pass.