Reviewing Team Purple.
Team Purple distribution available Here
Installation review:
I began, as any user should, by looking at the installation guide available Here. The guide is short with just a few bulleted points. It was all very simple except for a couple points of confusion:
- "run the junit task..." is a bit confusing. I was not immediately certain that this was the command "ant -f junit.build.xml."
- There is no mention about the URL of the project once it is deployed. I had to go into the tomcat manager to find the exact URL of it. It would be helpful to mention this in the installation guide.
Other then the above confusing points, it was quite simple to install and run the MyIsern-purple system.
I then ran the verify ant task. I was quite impressed with the sheer volume of tests running. It seems they tested the project quite thoroughly. Verify, however, does not pass. Some warnings from Findbugs causes it to fail. The 9 Findbugs warnings range from simple redundant ToString() operations to perhaps more complex problems involving non-serializable objects and HttpSessions.
Code format and conventions review:
I was quite surprised by the number of classes that were present in this code. However, the design seemed quite clean. I could not find many code conventions violations, though I did find some redundancy in certain parts of the code:
- The login() method in the LoginActionBean.java file separately checks if the username, password, or both failed. This can all be done with a single check to greatly reduce the complexity.
- In the CollaborationFormActionBean.java file on line 129 the .toString method is used on a String.
- Perhaps some of the class names are too verbose. For example CollaborationFormActionBean is a bit long for a class name.
Most of the code seemed to follow the guidelines quite well. I could not find many violations.
Test case review:
As I mentioned earlier, there are a rather large number of tests for this project. Running the junit task takes around 30 seconds to complete with 42 total tests running.
Black Box Perspective:
Since black box testing should focus on I/O behavior, it must deal with the UI for this type of project. UI testing, however, can be difficult on this type of client-server application. While there were a large number of tests, particularly dealing with login/logout behavior, some of the more basic tests of the linking system were missing. To greater cover black box testing, it may be useful to create a series of tests (perhaps another test class) that checks all links and navigation through the system. A large part of web applications is navigation through the system, so it is important to test it.
There may also be an issue with concurrency, which is nearly impossible to test for. I would think it would fall into the black box perspective since concurrency issues come about when certain I/O events take place at certain times. There are no tests that deal with concurrency, though I do not think it is even feasible to test concurrency.
White Box Perspective:
The emma results were fairly good for this project, considering the difficulty of testing server-side components. The results from emma were
Emma Coverage summary
class: 88% (29/33)
method: 67% (172/255)
block: 61% (1908/3153)
line: 62% (405.1/656)
For many of the classes, general tests were performed over the entire class (or functionality), yet not many had tests for each individual method. The coarse granularity of the tests focused more on Black box testing. For example, the LoginActionBean class only have tests for the SecurityFilter and various standard login events. Each specific method of the class is not tested, as should be attempted with a white box testing perspective. Many very small tests could be added to test each small piece of code. This could increase the coverage as well.
Break Da Buggah:
I think many people had trouble getting the system complete by this stage, so I was not surprised to find an unfinished section of the project. The "about us" link leads to a non-existent page called reports.jsp. This is simply a finishing problem and not an actual problem with the project.
Another small bug I found involved adding new objects. When a new collaboration is being added, the Years list is not filled with any values, so it is impossible to specify what years the collaboration took place during. This is simply a matter of propagating the list even when a new entry is being created.
User Interface review:
At this point in the project, I try not to focus on aesthetics of the pages at all. The "fluff" can be added later once all of the functionality is available.
The basic navigation of the system is quite nice. It is easy to view each list and navigate to the edit page. I like the feature that automatically propagates the edit form when the user clicks on the edit button for a particular row. It reduces mouse clicks and enables users to quickly and easily make changes. The use of thumbnails for researchers is nice as well. Perhaps even logo thumbnails could be added for the organizations table.
I think an easy way to see all of the data for every entry would be nice. The lists for each type (Researcher, Collaboration, or Organization) only contain the names. Some users may way to see every Researcher and their organizations in a single table, for example. Either an additional page is needed to display this information or the lists could contain all the data relevant to each object.
The system works quite well with a small amount of screen space. At 1/3 width and 1/3 height of my screen, I was still able to see the tables and all of the text boxes (on the add/edit pages).
One small change I would suggest is using a button instead of link for the "create" button after the tables. Using a button and perhaps placing an additional one just before the table could make it easier for new users.
Summary and Lessons Learned:
I learned a great deal from reviewing this project, since our project is less polished at this stage. While there are many components to this system, they are well integrated and nearly everything works perfectly. After reviewing this project, I may break up my project at this point to modularize it.
The login system using the SecurityFilter works very well. The login system used by my project is very different. Perhaps the SecurityFilter method is better.
I also realized how thorough the testing needs to be for this project. Since 1.2 this project has become much more complex and the volume and quality of test cases needs to reflect that. I will add many more tests to my own project now that I have seen many methods of testing this type of project.
Friday, November 16, 2007
Monday, November 5, 2007
25.WebAppQuestions
1. Explain in your own words the meaning of the web "request-response cycle".
The request-response cycle is the method by which web applications retrieve data from sources on the web. The client sends a request to a server that will use the data in the request to return a response. When the client performs some other action, it sends another response and the cycle continues.
2. Explain how servlets facilitate processing of the request-response cycle.
A servlet is a program that runs on the server to handle requests and return responses to the client. Unlike client applets that run on the client side and send requests, a servlet receives requests from the client, performs some operations, and returns a response.
3. How do you login to the Tomcat Manager?
To login to Tomcat Manager you simply run Tomcat on your local machine and connect to http://localhost:8080/ and click on the "Tomcat Manager" link. You are then prompted for the username and password that is defined in the conf/tomcat-users.xml file.
4. What is the Tomcat Manager used for in the StackStripes application?
The Tomcat Manager enables you to make the StackStripes program available to web users. The StackStripes application provides the Tomcat Manager with locations and configuration options of files that are to be deployed on the server and the manager makes them accessible to clients.
Any application that is deployed on Tomcat and therefore available to web users is contained in the webapps directory. Within the webapps directory, each application will have its own directory structure. The StackStripes application has, within its folder in the webapps directory, the following files/folders:
5. What is the directory and file layout of an installed web application like StackStripes? (This is NOT the same as the directory and file layout of the StackStripes distribution!)
META-INF - Contains meta file(s) with various meta data about the application.
WEB-INF - Contains the actual application and configuration files.
index.jsp - The default page that loads when no specific file is provided.
6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?
A war directory structure can be built using ANT with a build.xml file. The build.xml file for the StackStripes creates a war structure in the "war" target. It contains a war element that creates a .war file in a specific file location defined within the element.
7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?
If configured to automatically deploy, you can simply place a war directory into the webapps folder to install it on the server. The Ant task needs only to know the location of the webapps folder which is available in the $CATALINA_HOME environment variable.
8. What is the "Model2" architecture? What are its advantages?
Model2 is also knows as MVC (or Model View Controller) because it structures the client/server architecture into three components. The model contains any data or structures needed to maintain it (ie. database), the view contains the client presentation, and the controller accepts requests from the client and gives necessary data to the model. This architecture provides modularity and allows each component to be built in such a way that changes to one will not impact the others.
9. What are JSP pages? How are they related to servlets?
JSP (or JavaServer pages) are pages that are compiled into Java servlets on the server. They allow the server to dynamically generate pages in response to a client request.
10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?
Since they must be compiled into a servlet the first time the page is being retrieved, there is a delay for the JSP compiler to run on the server. However, once the servlet is compiled it is contained within memory and does not need to be compiled for further use.
11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?
JSTL tags are a set of tags usable within JSP pages provide methods for performing common tasks without the need of embedded Java. Since they allow you to perform tasks without embedded Java, they allow better separation of the application from the user interface defined in the JSP pages. The StackStripes system uses "c:forEach" tag to easily iterate and display all of the elements of the stack.
12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?
Stripes tags are tags defined by the Stripes web application framework. They enable you to easily link JSP tags with classes and methods in the Java application. Many Stripes tags are needed by the StackStripes system, for example the tag
< stripes:submit value="push" name="push"/>
causes the method called push to be evoked when the user clicks the "push" button.
13. What is HttpUnit? How is it different from JUnit? Why is it useful? What is an example use of HttpUnit from the StackStripes system?
HttpUnit provides a method for visiting and performing operation on websites automatically within code. It allows us to test systems that operate on the web, while JUnit is limited to a single local system. Every test that is performed on the server requires HttpUnit to run. Every test of the JavaActionBean class of the StackStripes uses HttpUnit.
14. What needed to be changed in order to implement the Double It button? What didn't need to be changed? What did you learn about the MVC design pattern from this exercise?
Very little had to be changed to implement the DoubleIt button. I simply had to add a new form to the JSP page and add the functionality to the StackModel class. The controller component did not have to be changed. This exercise illustrated how the MVC architecture allowed functionality to be added without changing every component.
15. What are the equivalence classes that need to be tested for the Double It button?
There were only two equivalence classes that needed to be tested: doubling an empty stack and doubling a non-empty stack.
16. Provide two screen images of your new StackStripes application with the Double It button, one showing the page before and one showing the page after hitting the "Double It" button.
And after clicking the "Double It" button.
17. What is the singleton design pattern? What is an example of its use in StackStripes? Why is it needed?
The singleton design pattern restricts the class to having only a single instantiation. For all users to interact with the same stack, this method is required. The stack in the StackStripes system is defined as a singleton by declaring the constructor as private and defining a single instance variable was static.
18. Some of the StackStripes tests exercise code on the "server side", while others exercise code on the "client" side. Which test classes exercise code on the "server", and which exercise code on the "client"? How does Emma deal with this to create appropriate coverage data?
The tests in TestStackActionBean are run on the server while the tests in TestStackModel run on the client. Emma can collect coverage data from both classes of JUnit test cases, but it cannot collect the data on the server until Tomcat is shutdown. That is why the emma.build.xml file shuts down the Tomcat server.
19. Running 'ant -f junit.build.xml' results in the following target invocations: tomcat.check, tomcat.undeploy, compile, war, tomcat.deploy, junit.tool, junit.report, junit. Explain what each of these targets do.
tomcat.check - checks to make sure Tomcat is currently running on the local machine and that it has the correct login/password.
tomcat.undeploy - deletes StackStripes from the Tomcat server.
compile – compiles the StackStripes system.
war – builds the war directory structure to be deployed on the Tomcat server.
tomcat.deploy – deploys the previously created war file to the Tomcat server.
junit.tool – runs all JUnit tests.
junit.report – creates the JUnit report files.
junit – Runs both the junit.tool and junit.report targets.
The request-response cycle is the method by which web applications retrieve data from sources on the web. The client sends a request to a server that will use the data in the request to return a response. When the client performs some other action, it sends another response and the cycle continues.
2. Explain how servlets facilitate processing of the request-response cycle.
A servlet is a program that runs on the server to handle requests and return responses to the client. Unlike client applets that run on the client side and send requests, a servlet receives requests from the client, performs some operations, and returns a response.
3. How do you login to the Tomcat Manager?
To login to Tomcat Manager you simply run Tomcat on your local machine and connect to http://localhost:8080/ and click on the "Tomcat Manager" link. You are then prompted for the username and password that is defined in the conf/tomcat-users.xml file.
4. What is the Tomcat Manager used for in the StackStripes application?
The Tomcat Manager enables you to make the StackStripes program available to web users. The StackStripes application provides the Tomcat Manager with locations and configuration options of files that are to be deployed on the server and the manager makes them accessible to clients.
Any application that is deployed on Tomcat and therefore available to web users is contained in the webapps directory. Within the webapps directory, each application will have its own directory structure. The StackStripes application has, within its folder in the webapps directory, the following files/folders:
5. What is the directory and file layout of an installed web application like StackStripes? (This is NOT the same as the directory and file layout of the StackStripes distribution!)
META-INF - Contains meta file(s) with various meta data about the application.
WEB-INF - Contains the actual application and configuration files.
index.jsp - The default page that loads when no specific file is provided.
6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?
A war directory structure can be built using ANT with a build.xml file. The build.xml file for the StackStripes creates a war structure in the "war" target. It contains a war element that creates a .war file in a specific file location defined within the element.
7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?
If configured to automatically deploy, you can simply place a war directory into the webapps folder to install it on the server. The Ant task needs only to know the location of the webapps folder which is available in the $CATALINA_HOME environment variable.
8. What is the "Model2" architecture? What are its advantages?
Model2 is also knows as MVC (or Model View Controller) because it structures the client/server architecture into three components. The model contains any data or structures needed to maintain it (ie. database), the view contains the client presentation, and the controller accepts requests from the client and gives necessary data to the model. This architecture provides modularity and allows each component to be built in such a way that changes to one will not impact the others.
9. What are JSP pages? How are they related to servlets?
JSP (or JavaServer pages) are pages that are compiled into Java servlets on the server. They allow the server to dynamically generate pages in response to a client request.
10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?
Since they must be compiled into a servlet the first time the page is being retrieved, there is a delay for the JSP compiler to run on the server. However, once the servlet is compiled it is contained within memory and does not need to be compiled for further use.
11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?
JSTL tags are a set of tags usable within JSP pages provide methods for performing common tasks without the need of embedded Java. Since they allow you to perform tasks without embedded Java, they allow better separation of the application from the user interface defined in the JSP pages. The StackStripes system uses "c:forEach" tag to easily iterate and display all of the elements of the stack.
12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?
Stripes tags are tags defined by the Stripes web application framework. They enable you to easily link JSP tags with classes and methods in the Java application. Many Stripes tags are needed by the StackStripes system, for example the tag
< stripes:submit value="push" name="push"/>
causes the method called push to be evoked when the user clicks the "push" button.
13. What is HttpUnit? How is it different from JUnit? Why is it useful? What is an example use of HttpUnit from the StackStripes system?
HttpUnit provides a method for visiting and performing operation on websites automatically within code. It allows us to test systems that operate on the web, while JUnit is limited to a single local system. Every test that is performed on the server requires HttpUnit to run. Every test of the JavaActionBean class of the StackStripes uses HttpUnit.
14. What needed to be changed in order to implement the Double It button? What didn't need to be changed? What did you learn about the MVC design pattern from this exercise?
Very little had to be changed to implement the DoubleIt button. I simply had to add a new form to the JSP page and add the functionality to the StackModel class. The controller component did not have to be changed. This exercise illustrated how the MVC architecture allowed functionality to be added without changing every component.
15. What are the equivalence classes that need to be tested for the Double It button?
There were only two equivalence classes that needed to be tested: doubling an empty stack and doubling a non-empty stack.
16. Provide two screen images of your new StackStripes application with the Double It button, one showing the page before and one showing the page after hitting the "Double It" button.
And after clicking the "Double It" button.
17. What is the singleton design pattern? What is an example of its use in StackStripes? Why is it needed?
The singleton design pattern restricts the class to having only a single instantiation. For all users to interact with the same stack, this method is required. The stack in the StackStripes system is defined as a singleton by declaring the constructor as private and defining a single instance variable was static.
18. Some of the StackStripes tests exercise code on the "server side", while others exercise code on the "client" side. Which test classes exercise code on the "server", and which exercise code on the "client"? How does Emma deal with this to create appropriate coverage data?
The tests in TestStackActionBean are run on the server while the tests in TestStackModel run on the client. Emma can collect coverage data from both classes of JUnit test cases, but it cannot collect the data on the server until Tomcat is shutdown. That is why the emma.build.xml file shuts down the Tomcat server.
19. Running 'ant -f junit.build.xml' results in the following target invocations: tomcat.check, tomcat.undeploy, compile, war, tomcat.deploy, junit.tool, junit.report, junit. Explain what each of these targets do.
tomcat.check - checks to make sure Tomcat is currently running on the local machine and that it has the correct login/password.
tomcat.undeploy - deletes StackStripes from the Tomcat server.
compile – compiles the StackStripes system.
war – builds the war directory structure to be deployed on the Tomcat server.
tomcat.deploy – deploys the previously created war file to the Tomcat server.
junit.tool – runs all JUnit tests.
junit.report – creates the JUnit report files.
junit – Runs both the junit.tool and junit.report targets.
26.StackStripesExtension
The distribution is available
Here
This was a simple exercise in learning the technology that will be used in later projects.
Installing Tomcat
I found this rather easy. I simply downloaded it, unzipped it, read some of the documentation to make sure I had everything correct, and ran it. I was able to connect to http://localhost:8080 right away without any problems.
Installing Stripes
Another rather easy task, as it simply involved downloading files and placing them in correct directories. After placing the stripes-examples.war file in the webapps directory, I was able to connect to http://localhost:8080/stripes-examples without any problems.
Installing StackStripes
Now this task was a bit more tricky. I was able to get it downloaded and deployed on Tomcat rather quickly, but came across some problems with getting all of the build.xml files to work correctly. I would always get a fail on verify because emma would not run properly. However, after reading the discussion boards about emma, I simply ran junit first and ran tomcat from the stackstripes project directory. After doing this, everything worked fine.
Improving coverage
When I first looked at the TestActionBean.java file, I was rather confused. It seemed that it was quite complicated to run tests on the server side of the project. However, after reading some more documentation and playing around with some of the code, I managed to get a good grasp on it. It appeared that the two methods that were not tested were the pop method in StackActionBean and the iterator in StackModel. I added test for these two methods and a error check for popping an empty stack to achieve 100% coverage in all areas.
The Double It button
It was surprisingly easy to create the "Double It" button and functionality. I did, however, have one strange problem with concurrency. There are some concurrency issues when iterating over a stack and pushing new elements on it at the same time. To overcome this, my doubleIt method first copies the entire stack to a temporary location then pushes the new members onto the original stack. This prevents concurrency problems with the iterator.
I also added one additional test of this method to keep emma coverage at 100%.
Conclusions
Overall this was a pretty straightforward task that allowed me to learn some of the technology we will need in the future. I like the simplicity of Stripes and the ease of adding new components. I think I am now ready to do more complex work with this technology.
Here
This was a simple exercise in learning the technology that will be used in later projects.
Installing Tomcat
I found this rather easy. I simply downloaded it, unzipped it, read some of the documentation to make sure I had everything correct, and ran it. I was able to connect to http://localhost:8080 right away without any problems.
Installing Stripes
Another rather easy task, as it simply involved downloading files and placing them in correct directories. After placing the stripes-examples.war file in the webapps directory, I was able to connect to http://localhost:8080/stripes-examples without any problems.
Installing StackStripes
Now this task was a bit more tricky. I was able to get it downloaded and deployed on Tomcat rather quickly, but came across some problems with getting all of the build.xml files to work correctly. I would always get a fail on verify because emma would not run properly. However, after reading the discussion boards about emma, I simply ran junit first and ran tomcat from the stackstripes project directory. After doing this, everything worked fine.
Improving coverage
When I first looked at the TestActionBean.java file, I was rather confused. It seemed that it was quite complicated to run tests on the server side of the project. However, after reading some more documentation and playing around with some of the code, I managed to get a good grasp on it. It appeared that the two methods that were not tested were the pop method in StackActionBean and the iterator in StackModel. I added test for these two methods and a error check for popping an empty stack to achieve 100% coverage in all areas.
The Double It button
It was surprisingly easy to create the "Double It" button and functionality. I did, however, have one strange problem with concurrency. There are some concurrency issues when iterating over a stack and pushing new elements on it at the same time. To overcome this, my doubleIt method first copies the entire stack to a temporary location then pushes the new members onto the original stack. This prevents concurrency problems with the iterator.
I also added one additional test of this method to keep emma coverage at 100%.
Conclusions
Overall this was a pretty straightforward task that allowed me to learn some of the technology we will need in the future. I like the simplicity of Stripes and the ease of adding new components. I think I am now ready to do more complex work with this technology.
Subscribe to:
Posts (Atom)