12.Webspider Review

Program author: Jung Kim

1. Installation Review
I. Running software
Jung Kim's program pretty much worked "right out of the box." I was able to extract the file successfully, and I could import it with no problem.

II. Build tests

JUnit: It ran successfully.

CheckStyle: CheckStyle had one error.
"Using the '.*' form of import should be avoided - java.util.logging.*."
Upon looking at his code, he didn't even use this library so I deleted it and checkstyle ran fine.

PMD: It ran successfully.

FindBugs: It ran successfully.

Emma: Emma did not run at all.
The error that was found was "C:\webspider-kimjung-1.0.927\emma.build.xml:68: input file C:\webspider-kimjung-1.0.927\build\emma\coverage.xml does not exist." I believe the lack of JUnit tests caused an error in Emma so that it cannot run at all.

Verify: Build failed because of the Emma error.

III. Building the jar file
ant -f dist.build.xml worked fine and created another distribution. ant jar also worked and created just the jar file.

IV. Invocation
I was able to successfully invoke "java -jar webspider-kimjung.jar -totallinks http://www.hackystat.org 100." But it gave me a total of one link. When I looked into the code, I realized that he didn't change much at all. The code still looks at the page that it's given and returns the number of links on that page alone. It doesn't travel to any other pages and retrieve links.

2. Code Format Review

File	Lines	Violation	Comments
WebSpiderExample.java	7	ICS-SE-Java-2	Do not use wild cards in import statements.
WebSpiderExample.java	12, 43, 44, ...	EJS-33	Keep code and comments in sync

3. Test Case Review
There simply was no test cases. Not even a JUnit annotation was present. In order to break the program, all that's needed is to travel outside of the format originally given. So if I was to enter "java -jar webspider-kimjung.jar http://www.hackystat.org” I would get an array out of bound error. I also know that the last argument, which handles how many pages it need to travels till it stops, really does nothing at all. There is no ways to distinguish from -totallinks to -mostpopular nor is there any kind of logging available in the code. In the end, there really isn't much to review at all.

4. Summary
I really didn't learn much from this exercise at all. Seeing as Jung Kim's assignment didn't really leave me much to work with, I couldn't really learn much from this experience. The sum total number of things I did was 4. I fixed a checkstyle error, figured out that Emma won't run without any test to run on, read code that was basically unchanged, and wrote a blog. I really wish I could have learned something from this experience but after reading Randy Cox's blog, I generally understand the point that this lesson is trying to get across. I should not look at a program as being done until I've crossed over to the other side, users versus programmers, and actually try to run my program from that perspective. I should experience everything from first installing the package on a fresh system to actually trying to break the program as a user and not a programmer.

Although I did not get to really think much about black box or white box testing with this program, I do see the difference. After reading other people's blogs and experience, it seems like black box testing aligns more with the point of view of the user. You put in something and expect something to come out. If what comes out is not what you expect, then something wrong. On the other hand, white box testing is generally good for programmers that want to make sure all the methods are being executed. If a code doesn't have 100% coverage, then you know that one of you methods, catch statements, etc. aren't being used. This helps to write more tests and eventually have a more robust code.