Wednesday, October 17, 2007

22.MyISERN-1.1.Review

1. Installation Review:

I decided to review Hong Nguyen project because it was among the few left over, and because I worked with him at the library and I'm curious to see how his project came out. I was able to download the installation file from their code.google.com website with no problems. From there, I was able to launch the system without using ant or eclipse and even got a nifty help feature when I just called the jar file. I also got an error telling me that there were no arguments so I know that at least that part is error free. I was able to run the verify build task with no problem and it completed successfully. I was also able to run the program normally, calling all the tables finding certain researchers, and etc. with no problems at all. It was very easy to use the program normally because of the help file.

2. Code format and conventions review

I didn't really find any code format and convention errors. If I was to be really picky, then I would say that some of the parameter names could have been named better but the general meaning is still easily derived from the names that they have chosen.

3. Test case review

Black Box testing:
All the tests were successful and it seem like they have a test for pretty much every single scenario. What's important for black box testing is testing for omission and it seems like the tests are very complete in the sense that they cover every single viable input. Since this program simply prints out the information it contains, black box testing consists mostly of ensuring that the right information is outputted. This Hong's group was smart in creating fake files and making sure that the data was complete and true.

White Box testing:
For line coverage, EMMA came up with:
class 100%
method 100%
block 98%
line 98%

This is quite amazing since our group was only able to get to 96% for our block coverage. After looking at the code, I found that the coverage wasn't 100% because there were lines that could have only been passed through if there was an error within the XML files, an error with linking, or errors with duplicate values.

Break the buggah:
The program was able to handle all the input I could give it. I ran through all the different possible inputs and their erroneous versions as well. I tried to test for all the different cases of omission and misspelling. Since this program really doesn't do much then listing the information it has in the XML files, it's really easy to code so that it is not error prone.

4. Summary and Lessons Learned

For previous review assignments I was usually handed code that wasn't always complete or didn't have much or any testing at all, so this was a great learning experience. I learned a lot about black box testing and just what it is exactly. I learned that black box testing is used to ensure that the data that comes out was the "right" data and that there were no omission errors. What I've learned from reviewing Hong's group's code was that I should try to test for more. Hong' group tested to see if their code would work with erroneous XML data and I should have done that too because it not only tests to see if the linking is working but also tests to see if duplicates were caught or not. It would have also been good to test if the XML files were found at all and to send out an error if that occurred. Basically I learned to test for complete coverage over the whole system and not just the code. I can try and pass through every single line of code but I should also test that everything works from when you start the program and it looks for data file to the output being correct.

No comments: