16. MyIsernReview

For this review, I reviewed the MyIsern1.0 system for Sonwright Gomez, who was a part of the myisern-1-blue group.

1. Installation review

Installation was straightforward - the package downloaded and unzipped fine. Verify passed. The only point I would mention here is that the JAR file was included with the installation, which added 2 megabytes to the archive.

2. Code format and conventions review

The following formatting violations are noted:

File	Line Number	Violation	Notes
MyIsernXmlLoader.java	31	EJS-35	Use meaningful Javadoc comments - should not mention it is 'sample' code anymore
MyIsernXmlLoader.java	152, 224, 288	EJS-9	Explain the meaning of the constant 3000.
MyIsernXmlLoader.java	211	EJS-36	Use /* ... */ to comment code rather than //

3. Test Case Review

Black Box: The only test cases in the code assume the test data equals the sample data. Unfortunately, these test cases will fail if the sample XML data changes.

The following tests are missing from the code:

- Null entries for values in an entry (e.g. 0-character strings)
- Empty XML file (e.g. 0 bytes, but exists)
- No XML file (e.g. does not exist in file system)
- File with long field values, but are still valid
- Entry with an invalid type (e.g. a letter in the year field)

White Box: EMMA reports 100% code coverage. This means that all code that is written is executed in the test cases that were written.

Break da buggah: After executing the black box tests, the following results occurred:

- Null entries for values in an entry: NullPointerException
- Empty XML file (e.g. 0 bytes, but exists): UnmarshalException/SAXParseException
- No XML file (e.g. does not exist in file system): FileNotFoundException
- File with long field values, but are still valid: executed OK
- Entry with an invalid type (e.g. a letter in the year field): NullPointerException


4. Summary and Lessons Learned

This exercise seemed very trivial. However, despite being very easy to do, it is still fairly easy to break. Many of these tests are circumstances that would not happen very often; however, when they do happen, the system can come crashing down and cause downtime.

This assignment was different from the last since we were told about two days before the due date that testing would be performed on our code. This gave us motivation to improve our test cases. It would be a good idea to possibly set aside a couple of days before the due date to work on test cases if the project is finished ahead of schedule.