Distribution of system available Here
Project home page is Here
All tasks were completed.
Difficulties
There were numerous difficulties in this section of the project. At first glance, I thought it would be rather easy, yet it turned out to be quite challenging. The annoyances of many of the components made getting the final project working quite difficult.
At our first meeting, we began discussing the UI and possible cases we needed to consider that might happen. It turned out that there were so many strange cases that could occur that the UI and underlying error checking system had to be quite complex. There were so many cases to consider and messages to give the user that just the UI because quite monstrous.
Once we had a partially working system, I began playing around with some of the data and trying to run as many cases as I could. At this point I realized how unforgiving JAXB and XML can be. Several times in this process the JAXB marshalling methods corrupted the XML files. It turns out that the JAXB Marshaller will sometimes write a format that will cause the Unmarshaller to crash with an exception. Our error checking mechanisms within the system had to be very robust to ensure this type of problem never occurs.
The testing of this system was a real problem. Since so many components of the additions in 1.2 rely on user interaction from System.in, I was unable to write many JUNIT test cases. Much of my testing was done by simply using the system and trying to break it. Entering the data turned out to be an exercise in breaking the system as well. On several occasions the system created corrupt XML files after I had entered a rather large amount of data, revealing a new bug. The SVN revert option was quite handy.
Group Organization
As we had done for our earlier version, myself and my teammate Shaoxuan Zhang met at the library for a long hacking session. After this 3 hour meeting on Thursday, we had most of the system complete. After that, we simply stayed in contact with email and Skype. It turned out quite well, since most of the data entry and debugging was difficult to work on as a team.
Future thoughts
At this point, the program is already becoming very large and somewhat difficult to manage. I think the incremental development we have been doing with 1.0, 1.1, and 1.2 made the design process difficult. Now that we have a more clear idea of how the entire final system will be, we can design a much more efficient system. There are many components in our current system that may not be used in the future. The slimming down of the system will make it much less buggy and more easily manageable in the future.
Lessons Learned
JAXB can be a pain, especially since the Marshaller and Unmarshaller do not behave the same when errors are present. I also learned the importance of early and complete design to keep the final system manageable. Finally, I gained some more experience with eclipse and the debugging features it provides.
Monday, October 22, 2007
19.UseCaseSpecification
Our use case wiki pages are available Here.
At first we were a little bit confused as to the particular format wanted. Most of the information available on the web about use cases involves stick figures and bubbles. Very few even mention UI mock-ups. Most pages show are very rigid templates, for example Here.
After realizing what we needed to do, we first created the use case for a simple log in. After that, we decided to come up with the "home page" that contains all of the features of the system. From there, we simply made a use case for each link from the home page (each has one specific function).
When I first pulled up Gimp and started working hard trying to make the pages look nice, I realized the aesthetics are unimportant. The objective is to outline the functionality, not the look of the final UI. In the end I threw away my complex diagrams and made very simple, functional diagrams.
At first we were a little bit confused as to the particular format wanted. Most of the information available on the web about use cases involves stick figures and bubbles. Very few even mention UI mock-ups. Most pages show are very rigid templates, for example Here.
After realizing what we needed to do, we first created the use case for a simple log in. After that, we decided to come up with the "home page" that contains all of the features of the system. From there, we simply made a use case for each link from the home page (each has one specific function).
When I first pulled up Gimp and started working hard trying to make the pages look nice, I realized the aesthetics are unimportant. The objective is to outline the functionality, not the look of the final UI. In the end I threw away my complex diagrams and made very simple, functional diagrams.
Wednesday, October 17, 2007
22.MyISERN-1.1.Review
Author: Chiao-Fen Zielinski-Liu
Installation
I was easily able to download and use the system. The UserGuide provided is quite straightforward and it was a simple task to get the system running. I was able to immediately run all of the queries through the commands of the form
java -jar myisern.jar
Loading the project into eclipse, however, was not quite as easy. Once imported, I got many errors from the build path. Since this always happens, I knew what environment variables to load to get the system working. The DevelopersGuide, however, does not clearly outline the required variables to import the system into eclipse. Overall it was rather easy to get all aspects of the system installed and running properly.
Code Format and Conventions
When I first looked at the source code for this project, I was rather surprised and pleased by the small number of classes and only one package. Some versions of this system can quickly become monstrously large. Most of the code fit the conventions rather well, however I did see some areas with some minor documentation and naming issues:
Test Cases
The test cases are, overall, rather extensive. The basic functionality of almost every unit is separately tested well, though I was confused to find all the tests in the same file (except for one that was in MyIsernXml.java). The majority of the testing seemed to be of the parser "MyIsernPrinter" class.
Black Box
Many of the units were tested for their specific I/O. For example, various input strings were tested on the MyIsernPrinter class and the return code was tested. However, specific end-to-end I/O black box tests were somewhat lacking. From a black box perspective, a test of the I/O relationship over the entire system can be useful.
White Box
Quite a lot of white box testing was done in this system. Emma shows the coverage to be over 90%. All the modules were tested for many different values. The details of the TablePrinter and MyIsernPrinter classes were especially well tested. However, from a white box perspective, exception testing was missing.
Testing for exceptions can be very important when analyzing the structure of the system. Rather than having the tests just throw the exception away, it can be helpful to test when an exception should be thrown and when they should not be.
Break Da Buggah
This system was quite difficult to break. I behaved quite well with nearly any input. Most of the problems I was able to find were simply unclear error messages and unexpected features.
For example, when running the system with no arguments a rather nice (though unexpected) thing occurs. Windows appear containing the contents of each table. While this functionality is nice, the documentation is rather unspecific about it and the requirements do not mention it. Some of the error messages are also quite unspecific and general.
After lots of trying, I did manage to get the system to behave unexpectedly. When running the following query:
-listOrganizations -collaborationLevelEquals 99999999999999999999
The following is output:
Print job was not successful
A check for values over the maximum integer size could fix this problem.
Summary and Lessons Learned
Overall this system is quite simple and concise. It handles many unexpected values rather well, delivers the data correctly, and even has some nice additional features. However, there are some places where the structure could be improved. Some of the functionality is rather rigidly implemented that may make future enhancement of the system difficult. For example, the class used to parse the command line may be very difficult to later expand. It uses a rather complex "code" type of system with many if statements that may be problematic in future development.
From this system I learned about the JFrame utility, which seems like a really nice tool for displaying various objects to the user. I think it may come in handy in future projects. I also saw some places where my own system could be improved, for example the handling of very unexpected input values.
Installation
I was easily able to download and use the system. The UserGuide provided is quite straightforward and it was a simple task to get the system running. I was able to immediately run all of the queries through the commands of the form
java -jar myisern.jar
Loading the project into eclipse, however, was not quite as easy. Once imported, I got many errors from the build path. Since this always happens, I knew what environment variables to load to get the system working. The DevelopersGuide, however, does not clearly outline the required variables to import the system into eclipse. Overall it was rather easy to get all aspects of the system installed and running properly.
Code Format and Conventions
When I first looked at the source code for this project, I was rather surprised and pleased by the small number of classes and only one package. Some versions of this system can quickly become monstrously large. Most of the code fit the conventions rather well, however I did see some areas with some minor documentation and naming issues:
| File | Lines | Violation | Comments |
| TestMyIsernXmlLoader.java | 18 | N/A | Author and comment unedited since example |
| PrinterData.java | 120,140,160,... | EJS-33 | Whitespace or moving comments may make reading easier |
| MyIsernPrinter.java | 16 | EJS-7 | White space needed between methods |
Test Cases
The test cases are, overall, rather extensive. The basic functionality of almost every unit is separately tested well, though I was confused to find all the tests in the same file (except for one that was in MyIsernXml.java). The majority of the testing seemed to be of the parser "MyIsernPrinter" class.
Black Box
Many of the units were tested for their specific I/O. For example, various input strings were tested on the MyIsernPrinter class and the return code was tested. However, specific end-to-end I/O black box tests were somewhat lacking. From a black box perspective, a test of the I/O relationship over the entire system can be useful.
White Box
Quite a lot of white box testing was done in this system. Emma shows the coverage to be over 90%. All the modules were tested for many different values. The details of the TablePrinter and MyIsernPrinter classes were especially well tested. However, from a white box perspective, exception testing was missing.
Testing for exceptions can be very important when analyzing the structure of the system. Rather than having the tests just throw the exception away, it can be helpful to test when an exception should be thrown and when they should not be.
Break Da Buggah
This system was quite difficult to break. I behaved quite well with nearly any input. Most of the problems I was able to find were simply unclear error messages and unexpected features.
For example, when running the system with no arguments a rather nice (though unexpected) thing occurs. Windows appear containing the contents of each table. While this functionality is nice, the documentation is rather unspecific about it and the requirements do not mention it. Some of the error messages are also quite unspecific and general.
After lots of trying, I did manage to get the system to behave unexpectedly. When running the following query:
-listOrganizations -collaborationLevelEquals 99999999999999999999
The following is output:
Print job was not successful
A check for values over the maximum integer size could fix this problem.
Summary and Lessons Learned
Overall this system is quite simple and concise. It handles many unexpected values rather well, delivers the data correctly, and even has some nice additional features. However, there are some places where the structure could be improved. Some of the functionality is rather rigidly implemented that may make future enhancement of the system difficult. For example, the class used to parse the command line may be very difficult to later expand. It uses a rather complex "code" type of system with many if statements that may be problematic in future development.
From this system I learned about the JFrame utility, which seems like a really nice tool for displaying various objects to the user. I think it may come in handy in future projects. I also saw some places where my own system could be improved, for example the handling of very unexpected input values.
Monday, October 15, 2007
18.MyISERN-1.1
Project download and wiki pages available at:
http://code.google.com/p/myisern-1-ivory/
We completed all tasks assigned to us.
Difficulties
In this section of the assignment, our project grew a great deal. Our structure may be overly complicated and is becoming much more difficult to manage. However, it deals with the problem quite well and has been tested enough that I have confidence it will be quite difficult to break.
One difficulty was the command-line parser. I first considered this to be one of the easiest components, but with some confusion and trying to get enum to work, it because rather annoying. Overall the project went quite smoothly and we completed all tasks without too much trouble.
Teamwork
In this phase we worked well together. Early on we defined all of the issues and components needed so we could more easily break up the work. On Thursday we met at the library and in a few hours were able to design and implement most of the system. After that we kept in contact with Skype and email. I think the issue driven design works very well.
Lessons learned
There were several times in this assignment when I realized how much more comfortable I am becoming with Java and the tools we are using. I can see I am also becoming much better are creating test cases. Just the experience of continually working on this project is teaching me a lot about software development.
I also learned how valuable a project outline is. The issue feature on Google projects provided my team with a way to easily outline the project and efficiently divide up work. I will definitely use this type of method in future group efforts if possible
http://code.google.com/p/myisern-1-ivory/
We completed all tasks assigned to us.
Difficulties
In this section of the assignment, our project grew a great deal. Our structure may be overly complicated and is becoming much more difficult to manage. However, it deals with the problem quite well and has been tested enough that I have confidence it will be quite difficult to break.
One difficulty was the command-line parser. I first considered this to be one of the easiest components, but with some confusion and trying to get enum to work, it because rather annoying. Overall the project went quite smoothly and we completed all tasks without too much trouble.
Teamwork
In this phase we worked well together. Early on we defined all of the issues and components needed so we could more easily break up the work. On Thursday we met at the library and in a few hours were able to design and implement most of the system. After that we kept in contact with Skype and email. I think the issue driven design works very well.
Lessons learned
There were several times in this assignment when I realized how much more comfortable I am becoming with Java and the tools we are using. I can see I am also becoming much better are creating test cases. Just the experience of continually working on this project is teaching me a lot about software development.
I also learned how valuable a project outline is. The issue feature on Google projects provided my team with a way to easily outline the project and efficiently divide up work. I will definitely use this type of method in future group efforts if possible
Wednesday, October 10, 2007
16.MyIsernReview
Author of reviewed code: Shaoxuan Zhang
Introduction
This was a very interesting exercise for me, as the person who's code I reviewed was my group member. Therefore, the code I reviewed is, at least partially, my own. This essentially provided me with an opportunity to look at my own product and try to critique it.
Installation review
Although I already had this entire project on my computer, I tried to download it and run it as though I had never done so before. Since there was no .jar file contained in the download package, I ran it by importing it into eclipse.
I was able to easily download the file from the link provided on Shaoxuan Zhang's blog entry. It was a simple task to import the project into eclipse and run it. I had no problems installing and running this software. It passed the verify.build.xml test without and errors. At this point I have no problems with the project.
Code format and conventions review
This was an interesting task, as I had previously read and worked on the code I was trying to review. Going over this code again just focusing on code format gave me a different outlook on the code. Despite my best efforts, however, I was only able to find one problem. A bit more white space between methods would have made the code slightly easier to read. My table of convention violations is only
Test case review
This was a particularly difficult area for me to critique, since it was my job to test the code. I tried to look at my own code with a critical eye and think of what was lacking in my own test cases.
Black box perspective
From a black box perspective, this was a difficult program to test. The requirements were just that the output be a series of tables containing the data from the XML files. There was no specification as to the format of the tables. Therefore, creating general test cases that considered the output of the entire system was nearly impossible.
Despite this, a test that parsed the output tables and compared them with expected values was missing.
White box perspective
This are was quite thoroughly tested. There were many tests for boundary conditions and illegal values. There were 8 separate tests for exceptions, as seen from the output of running JUNIT. Looking at the output from emma, there is only one section of code that was not tested, and that was the exception handing within of ExamplePrinter, the class that contained the main function. This section of code would only run if there was something wrong with any of the xml files used by main(). However, since the file names are hard coded, I see no way of testing this section of code. I could find no other missing tests from a white box perspective.
Break da buggah
It took me quite a long time to break this code, but I was able to find a problem. If the XML file is of an incorrect format, the program does not always behave correctly. For example, if an element is repeated twice with two different values, only the second will be displayed. For example, I edited collaborations.example.xml by adding an additional < Description> element, such as:
< Description>
A graduate student at the University of Hawaii spent the summer working in the University of Maryland research group.
</Description>
< Description>
This is a second description that does not belong here.
</Description>
This invalid XML format is not caught by the system and the output table contains
Summary and Lessons Learned
I got a fresh new perspective on my own project, and I think I did a fairly good job. I think Shaoxuan Zhang and I did a good job on the structure, design, implementation, and testing of the project. Perhaps the only thing I would change is to add some more complete black box tests.
I tried to critique my own code fairly, but I think it is impossible when you already know so much about it. It is much harder to critique and break your own code.
Introduction
This was a very interesting exercise for me, as the person who's code I reviewed was my group member. Therefore, the code I reviewed is, at least partially, my own. This essentially provided me with an opportunity to look at my own product and try to critique it.
Installation review
Although I already had this entire project on my computer, I tried to download it and run it as though I had never done so before. Since there was no .jar file contained in the download package, I ran it by importing it into eclipse.
I was able to easily download the file from the link provided on Shaoxuan Zhang's blog entry. It was a simple task to import the project into eclipse and run it. I had no problems installing and running this software. It passed the verify.build.xml test without and errors. At this point I have no problems with the project.
Code format and conventions review
This was an interesting task, as I had previously read and worked on the code I was trying to review. Going over this code again just focusing on code format gave me a different outlook on the code. Despite my best efforts, however, I was only able to find one problem. A bit more white space between methods would have made the code slightly easier to read. My table of convention violations is only
| File | Lines | Violation | Comments |
| ExamplePrinter.java, TablePrinter.java, ... | 12,10,... | EJS-7 | White space needed between methods |
Test case review
This was a particularly difficult area for me to critique, since it was my job to test the code. I tried to look at my own code with a critical eye and think of what was lacking in my own test cases.
Black box perspective
From a black box perspective, this was a difficult program to test. The requirements were just that the output be a series of tables containing the data from the XML files. There was no specification as to the format of the tables. Therefore, creating general test cases that considered the output of the entire system was nearly impossible.
Despite this, a test that parsed the output tables and compared them with expected values was missing.
White box perspective
This are was quite thoroughly tested. There were many tests for boundary conditions and illegal values. There were 8 separate tests for exceptions, as seen from the output of running JUNIT. Looking at the output from emma, there is only one section of code that was not tested, and that was the exception handing within of ExamplePrinter, the class that contained the main function. This section of code would only run if there was something wrong with any of the xml files used by main(). However, since the file names are hard coded, I see no way of testing this section of code. I could find no other missing tests from a white box perspective.
Break da buggah
It took me quite a long time to break this code, but I was able to find a problem. If the XML file is of an incorrect format, the program does not always behave correctly. For example, if an element is repeated twice with two different values, only the second will be displayed. For example, I edited collaborations.example.xml by adding an additional < Description> element, such as:
< Description>
A graduate student at the University of Hawaii spent the summer working in the University of Maryland research group.
</Description>
< Description>
This is a second description that does not belong here.
</Description>
This invalid XML format is not caught by the system and the output table contains
...--------------------------------------------------
...| Years | Description |
...--------------------------------------------------
...| 2005 | This is a second description that does |
...| 2006 | not belong here. |
...--------------------------------------------------
Summary and Lessons Learned
I got a fresh new perspective on my own project, and I think I did a fairly good job. I think Shaoxuan Zhang and I did a good job on the structure, design, implementation, and testing of the project. Perhaps the only thing I would change is to add some more complete black box tests.
I tried to critique my own code fairly, but I think it is impossible when you already know so much about it. It is much harder to critique and break your own code.
Monday, October 8, 2007
15.MyISERN-1.0
Group Ivory distribution available
HERE
Group Ivory Team: Shaoxuan Zhang, Ben Karsin
Lessons about JAXB:
The example given to us for this project was a great help. It provided many of the necessary functionality of JAXB. Without the example to show us the many complicated classes and methods of JAXB, this project would have been extremely difficult.
While adapting the sample code to meet our project, however, I learned quite a lot about JAXB.
XML
I was able to quickly understand the structure of the XML documents. I was expecting them to be much more complicated. Once we understood the structure of the documents and what needed to be done with them, we were able to work on the rather tedious task of creating the structure and implementation of this project.
Major Issues
One of the major issues we had was creating a nice table format. There was no specification in the assignment for a desired format, so I spent quite a bit of time trying to come up with an optimal solution. I turned out, however, that my partner was able to design a very nice looking table that is able to work well with different sizes and numbers of entries.
During this project both my teammate and I because quite frustrated with findbugs. Some of the errors given were unnecessary, annoying to overcome. For example, it tends to complain about
if (a != b) {
...
}
else {
...
}
This is really an insignificant problem but can become quite annoying. We also had some rather annoying little problems with javadocs giving errors if package.html is not of an exact format.
Overall, the majority of the issues we faced were not very large, but added up to be quite an annoyance. We eventually overcame them all and have a quite nice and stable project.
Teamwork
On the first day after the project was assigned, we decided to meet at the library. Upon meeting, however, we decided that it was an unnecessary waste of time to meet every day in person, so we decided to just use email, phone, and Skype to communicate regularly. The technology helped us communicate, but the project is fundamentally difficult to divide. We both began by reading the given documentation and tutorials, and began designing separately. Shaoxuan came up with a working program before me, so we decided to use his. He completed the design and implementation of the core of the project, while I was responsible for the testing, documentation, and other various small tasks needed to finish the project.
In the future, I think we should schedule specific IM or Skype meetings at a specific time each day, as the delay of email can be inefficient. I hope that future projects are more divisible and we are able to partition the work. We ended up getting the task done rather well, but I think if we were able to better divide the work, our time would have been used much more efficiently.
HERE
Group Ivory Team: Shaoxuan Zhang, Ben Karsin
Lessons about JAXB:
The example given to us for this project was a great help. It provided many of the necessary functionality of JAXB. Without the example to show us the many complicated classes and methods of JAXB, this project would have been extremely difficult.
While adapting the sample code to meet our project, however, I learned quite a lot about JAXB.
XML
I was able to quickly understand the structure of the XML documents. I was expecting them to be much more complicated. Once we understood the structure of the documents and what needed to be done with them, we were able to work on the rather tedious task of creating the structure and implementation of this project.
Major Issues
One of the major issues we had was creating a nice table format. There was no specification in the assignment for a desired format, so I spent quite a bit of time trying to come up with an optimal solution. I turned out, however, that my partner was able to design a very nice looking table that is able to work well with different sizes and numbers of entries.
During this project both my teammate and I because quite frustrated with findbugs. Some of the errors given were unnecessary, annoying to overcome. For example, it tends to complain about
if (a != b) {
...
}
else {
...
}
This is really an insignificant problem but can become quite annoying. We also had some rather annoying little problems with javadocs giving errors if package.html is not of an exact format.
Overall, the majority of the issues we faced were not very large, but added up to be quite an annoyance. We eventually overcame them all and have a quite nice and stable project.
Teamwork
On the first day after the project was assigned, we decided to meet at the library. Upon meeting, however, we decided that it was an unnecessary waste of time to meet every day in person, so we decided to just use email, phone, and Skype to communicate regularly. The technology helped us communicate, but the project is fundamentally difficult to divide. We both began by reading the given documentation and tutorials, and began designing separately. Shaoxuan came up with a working program before me, so we decided to use his. He completed the design and implementation of the core of the project, while I was responsible for the testing, documentation, and other various small tasks needed to finish the project.
In the future, I think we should schedule specific IM or Skype meetings at a specific time each day, as the delay of email can be inefficient. I hope that future projects are more divisible and we are able to partition the work. We ended up getting the task done rather well, but I think if we were able to better divide the work, our time would have been used much more efficiently.
14.CM.Practice
All three tasks were completed.
Installation:
Downloading and installing TortoiseSVN was very easy and only took a few minutes. It did, however, take me a little while to get used to the interface for this program. Once I played around with the interface, however, I found it very easy to retrieve, commit, and update SVN projets.
Once I installed TortoiseSVN, i downloaded the stack project, added a period to one of the javadoc sentences, and committed it. This was a rather fast and easy task.
Problems Encountered:
I ran into only a few problems during this small practice. Most of them were caused by the rather confusing interface at Google project hosting. Sometimes it was difficult to find certain options or menus on the website.
The biggest problem I had was setting up the automatic email notification for the -svn group. The text boxes to input the email addresses to send notification to were in an unexpected area. I had to keep slightly changing my project and re-committing it. I eventually figured it out and was able to get the notification on my Google group.
Lessons Learned:
I learned to use SVN. It is quite a useful tool and I am very glad that I now know how to use it and how to host projects. This assignment was a very easy introduction to some very useful and powerful software.
Installation:
Downloading and installing TortoiseSVN was very easy and only took a few minutes. It did, however, take me a little while to get used to the interface for this program. Once I played around with the interface, however, I found it very easy to retrieve, commit, and update SVN projets.
Once I installed TortoiseSVN, i downloaded the stack project, added a period to one of the javadoc sentences, and committed it. This was a rather fast and easy task.
Problems Encountered:
I ran into only a few problems during this small practice. Most of them were caused by the rather confusing interface at Google project hosting. Sometimes it was difficult to find certain options or menus on the website.
The biggest problem I had was setting up the automatic email notification for the -svn group. The text boxes to input the email addresses to send notification to were in an unexpected area. I had to keep slightly changing my project and re-committing it. I eventually figured it out and was able to get the notification on my Google group.
Lessons Learned:
I learned to use SVN. It is quite a useful tool and I am very glad that I now know how to use it and how to host projects. This assignment was a very easy introduction to some very useful and powerful software.
Monday, October 1, 2007
12.WebSpiderReview
Author of package under review: Edward Kim
Introduction
When I first began reviewing this code, I was quite surprised by the lack of support classes and methods. The entire program is contained within a single class and has only 3 methods. However, when looking closer, it is quite concise and seems to accomplish the tasks. There are not many tests, but they provide good coverage. I think this is a case where more testing is needed to produce a stable program.
Installation
It was quite simple to run download and run the package from Edward Kim. The zip file contained everything I needed to run all of the tools. I simply opened my command line and ran all of the necessary files.
I used ant to run all of the provided xml build files. The output data from the junit tests were quite extensive, but I was able to run all of the tools without any errors. For simplicity of testing, it would be nice to display a simple pass or fail for each of the junit tests. I was also able to create the jar file using dist.build.xml without any problems.
I then ran the command
java -jar webspider-{classmate}.jar -totallinks http://www.hackystat.org 100
The results were that 3211 links were found. It seemed to run this task correctly.
Code Format and Conventions
Upon opening the source file, I immediately noticed that the example file was used and the additional features were added. While it is nice to use this as a foundation, it is important to remember to change the header comments and add detailed comments about added features.
Test Case Review
There were few test cases provided for this application. The file TestWebSpider.java contained a few tests that ran the application with several different settings. Some of the tests took a long time to execute and produced excessive output because the program was run over a website with a link depth of 100. Cases could be tested much faster and cleaner with more, smaller tests.
Black Box Perspective
There was no testing of abnormal I/O combinations. Only one test was run that verified correct output. Test of each method should be done from this perspective to ensure proper execution for a wide range of input. For black box testing, the addition of tests done over a controlled set of web links would be very useful. I would add tests something similar to Randy Cox's test website, available at
http://www2.hawaii.edu/~randycox/11.WebSpider/test/main.htm
In addition, it would be helpful to test each method separately and compare the output. Tests should be done over the method mostPopular() with different lists of Strings being passed (including an empty list and a very long list). Likewise, tests could be done over the crawl() and getNumLinks() methods with different combinations of input. The resulting tests should have their results compared to the "expected" results.
White Box Perspective
Coverage was very well tested. Emma reported that coverage was well over 90%. While all the code was tested in some way, exceptions were not tested for, and abnormal cases were not considered. At the very least some tests where exceptions should be thrown are needed. Boundary conditions are also not tested, and in some cases unhandled exceptions will result. For example, if a null is given as input to one of the methods.
Some tests that should be added include testing passing null values to the methods. An example of this would be sending the mostPopular() method a null value instead of a list.
Break da buggah
To break this program, I simply began trying strange input. I first used the control website provided above to ensure it gave correct output. It passed these tests. I then tried simply providing not enough input. The command was
java -jar webspider-eykim.jar -totallinks
The result was
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at edu.hawaii.webspider.WebSpiderExample.main(WebSpiderExample.java:112)
There are problems with catching erroneous I/O that could be easily fixed. Additional testing could have revealed these errors.
Lessons Learned
Doing this type of critical review, I see many errors that I made myself. For example, I had quite inadequate testing in my version of this same program. In breaking this program, I see that I should write much more extensive tests for my own future program. Black box testing, specifically, tends to be under emphasized. Catching cases where strange input can break your program is very important. You never know what the user will do with your program.
Reading this code also showed me how simply and concisely this program could be done. My version had several additional classes and many complex algorithms and data structures. This version, however, was done quite cleanly with only a few short methods. It shows me that I should spend more time on program design rather then jumping strait into coding.
Introduction
When I first began reviewing this code, I was quite surprised by the lack of support classes and methods. The entire program is contained within a single class and has only 3 methods. However, when looking closer, it is quite concise and seems to accomplish the tasks. There are not many tests, but they provide good coverage. I think this is a case where more testing is needed to produce a stable program.
Installation
It was quite simple to run download and run the package from Edward Kim. The zip file contained everything I needed to run all of the tools. I simply opened my command line and ran all of the necessary files.
I used ant to run all of the provided xml build files. The output data from the junit tests were quite extensive, but I was able to run all of the tools without any errors. For simplicity of testing, it would be nice to display a simple pass or fail for each of the junit tests. I was also able to create the jar file using dist.build.xml without any problems.
I then ran the command
java -jar webspider-{classmate}.jar -totallinks http://www.hackystat.org 100
The results were that 3211 links were found. It seemed to run this task correctly.
Code Format and Conventions
Upon opening the source file, I immediately noticed that the example file was used and the additional features were added. While it is nice to use this as a foundation, it is important to remember to change the header comments and add detailed comments about added features.
| File | Lines | Violation | Comments |
| WebSpiderExample.java | 24,26,83 | EJS-13 | All letters of URL are capitalized. |
| WebSpiderExample.java | 24,25,26 | EJS-39 | Global variables not documented. |
| WebSpiderExample.java | 36,138,213 | EJS-56 | No pre/most conditions. |
| WebSpiderExample.java | 63,66,163 | EJS-9 | Variables names wc and resp not clear. |
| WebSpiderExample.java, TestWebSpider.java | N/A | EJS-40,41 | No Summary of files/package |
Test Case Review
There were few test cases provided for this application. The file TestWebSpider.java contained a few tests that ran the application with several different settings. Some of the tests took a long time to execute and produced excessive output because the program was run over a website with a link depth of 100. Cases could be tested much faster and cleaner with more, smaller tests.
Black Box Perspective
There was no testing of abnormal I/O combinations. Only one test was run that verified correct output. Test of each method should be done from this perspective to ensure proper execution for a wide range of input. For black box testing, the addition of tests done over a controlled set of web links would be very useful. I would add tests something similar to Randy Cox's test website, available at
http://www2.hawaii.edu/~randycox/11.WebSpider/test/main.htm
In addition, it would be helpful to test each method separately and compare the output. Tests should be done over the method mostPopular() with different lists of Strings being passed (including an empty list and a very long list). Likewise, tests could be done over the crawl() and getNumLinks() methods with different combinations of input. The resulting tests should have their results compared to the "expected" results.
White Box Perspective
Coverage was very well tested. Emma reported that coverage was well over 90%. While all the code was tested in some way, exceptions were not tested for, and abnormal cases were not considered. At the very least some tests where exceptions should be thrown are needed. Boundary conditions are also not tested, and in some cases unhandled exceptions will result. For example, if a null is given as input to one of the methods.
Some tests that should be added include testing passing null values to the methods. An example of this would be sending the mostPopular() method a null value instead of a list.
Break da buggah
To break this program, I simply began trying strange input. I first used the control website provided above to ensure it gave correct output. It passed these tests. I then tried simply providing not enough input. The command was
java -jar webspider-eykim.jar -totallinks
The result was
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at edu.hawaii.webspider.WebSpiderExample.main(WebSpiderExample.java:112)
There are problems with catching erroneous I/O that could be easily fixed. Additional testing could have revealed these errors.
Lessons Learned
Doing this type of critical review, I see many errors that I made myself. For example, I had quite inadequate testing in my version of this same program. In breaking this program, I see that I should write much more extensive tests for my own future program. Black box testing, specifically, tends to be under emphasized. Catching cases where strange input can break your program is very important. You never know what the user will do with your program.
Reading this code also showed me how simply and concisely this program could be done. My version had several additional classes and many complex algorithms and data structures. This version, however, was done quite cleanly with only a few short methods. It shows me that I should spend more time on program design rather then jumping strait into coding.
Subscribe to:
Posts (Atom)