This week began the review phase of our project. Everyone was tasked with looking over each others' code and making comments to it. For our project Aric took a look at our xml files and noted that we had the wrong project name in a few of them. He also suggested changing the login and getInfo method in Lender.java to abstract which I took into consideration. He stated that there were several JavaDoc comments that had flimsy description so we expanded them. Two reviewers commented that we hard coded the login and password for TestLender.java. I guess I forgot to change that after I changed how arguments are passed in TestUhManoa.java. Philip noted we had @Ignore in our test cases, which we only added to pass verify.build.xml. Two reviewers noted our argument for specifying the library was different from the standard so I changed that. Ancheta suggested we turn the Lender class into a interface because we only had print statements in there but we prefer to keep it as a superclass so that we could use it later in the future for nonspecified library methods. The only two individuals who didn't make a comment was Flestado and Sanchez.
For my reviews I was tasked with the red, silver, and gold teams. For gold I was tasked with looking at the JavaDoc comments. I made a comment for the LibraryVault.java because their parameter descriptions was gibberish. For red I was tasked with looking at the main method
where I didn't see any problems. For silver I was tasked with looking at Library.java, User.java, Book.java, and the testing suite. I made a suggesting to have toString in Book.java to return both the book title and due date. I also suggested dropping the toString in User.java because it does the same thing as getUserID.
The act of posting comments to the code in Google Project Hosting was awkward for me because in order to have the "Publish Comments" appear I had to add a comment and save, refresh the page, and add the comment again. Looking at other groups code gave me alot of ideas that I would like to incorporate into my group's code. Probably the work that needs to get done the most is in the test cases. Next time I would probably clarify that it's alright to look at code outside the reviewer's main task. I would probably do the same to the tasks assigned to me.
Friday, October 24, 2008
Sunday, October 19, 2008
DueDates
Recently I started a Java project named DueDates. What this program does is retrieve information from libraries and allows a user to find out what books they have borrowed along with their due dates. In this project I worked with Jon Ly we put together a program that allowed a user to access the UH Library system and find out the books he has borrowed. The project can be found here and project files can be downloaded here.
Design
One of our first problems was to figure out how to divide up the classes. We wanted to make sure the program was extensible so that in the future we could easily add more libraries and features. We created a Lender superclass which in the future we hope will have generic methods that can access libraries that can't be found in the program. There is also a toFormattedString method in it that we use standardize the output of all libraries. In the future we could also add other standardized features to the Lender class like a GUI.
From that superclass we created library subclasses that had login and getInfo methods specific to each library. Later we can add other methods that might be unique for each library.
Problems and Resolution
Using HTTPUnit we had the program look for the first table with the string "Renew?" on the UH page which should be the table containing the information on books borrowed. It's doubtful that any other table will start with that string and testing for that possibility would be slightly difficult since the only other possible table before that one is the Patron Block table which I believe is related to late fees.
Since we moved all our methods to other classes there was only a static main method in the main class so a Singleton error cropped up while running PMD. This was an error I've never seen before and through some research I found it can be fixed by adding a private constructor.
One of our biggest problems was making the test cases. It took me a while to figure out how to pass arguments to test cases. I couldn't tell if it worked because we couldn't figure out how to get the login method test to work. The method was suppose to return a object, in this case a WebConversation object, but we couldn't figure how to check if the correct object was returned. So we had to add a @Ignore to get the program to pass verify.build.xml.
Another problem I noticed was that when running Emma it would produce a Rhino classes error. I wasn't exactly sure whether the cause was our test cases or Rhino which we were told we could ignore.
Future Features
In the future we hope to add other libraries including the Hawaii State Library. The Hawaii State Library system wasn't the focus of this phase of the project but we had a cursory class for it. There are a few problems with it, including a slow info retrieval and getting accurate information, that we hope to fix with the next phase of the program. We also plan to add the ability to retrieve more information besides just borrowed books including fees, requests and holds. We also want to allow the user to renew books through the program. It'll be nice if the program had an alert system that a user can schedule to warn him when something is almost due. Also the ability to send a feed to different programs would be cool. Lastly, even though it's unlikely, I'll like the program to attempt to access other libraries that haven't been covered by the program.
Group Project
Our group met at the Hamilton library about 3 times, spending an average of an hour each time working on the project. We had discussions on the design of the program and what part of the project we will be working on. We made sure to commit frequently throughout the week. I think that the way we organized ourselves was effective and allowed us to get the program done in a timely manner.
As for Google Project Hosting I found the Issues tab to be an effective way for members of a project to point out problems that arise during the course of the project. Probably the only annoyance I had with Google Project is the amount of emails I got. In the past week I received 40 emails from the project. I understand getting an email for rather important items like commit changes but wiki changes and some issue reports are things that I really don't need to know about. There should be some sort of priority on whether something is email worthy.
Design
One of our first problems was to figure out how to divide up the classes. We wanted to make sure the program was extensible so that in the future we could easily add more libraries and features. We created a Lender superclass which in the future we hope will have generic methods that can access libraries that can't be found in the program. There is also a toFormattedString method in it that we use standardize the output of all libraries. In the future we could also add other standardized features to the Lender class like a GUI.
From that superclass we created library subclasses that had login and getInfo methods specific to each library. Later we can add other methods that might be unique for each library.
Problems and Resolution
Using HTTPUnit we had the program look for the first table with the string "Renew?" on the UH page which should be the table containing the information on books borrowed. It's doubtful that any other table will start with that string and testing for that possibility would be slightly difficult since the only other possible table before that one is the Patron Block table which I believe is related to late fees.
Since we moved all our methods to other classes there was only a static main method in the main class so a Singleton error cropped up while running PMD. This was an error I've never seen before and through some research I found it can be fixed by adding a private constructor.
One of our biggest problems was making the test cases. It took me a while to figure out how to pass arguments to test cases. I couldn't tell if it worked because we couldn't figure out how to get the login method test to work. The method was suppose to return a object, in this case a WebConversation object, but we couldn't figure how to check if the correct object was returned. So we had to add a @Ignore to get the program to pass verify.build.xml.
Another problem I noticed was that when running Emma it would produce a Rhino classes error. I wasn't exactly sure whether the cause was our test cases or Rhino which we were told we could ignore.
Future Features
In the future we hope to add other libraries including the Hawaii State Library. The Hawaii State Library system wasn't the focus of this phase of the project but we had a cursory class for it. There are a few problems with it, including a slow info retrieval and getting accurate information, that we hope to fix with the next phase of the program. We also plan to add the ability to retrieve more information besides just borrowed books including fees, requests and holds. We also want to allow the user to renew books through the program. It'll be nice if the program had an alert system that a user can schedule to warn him when something is almost due. Also the ability to send a feed to different programs would be cool. Lastly, even though it's unlikely, I'll like the program to attempt to access other libraries that haven't been covered by the program.
Group Project
Our group met at the Hamilton library about 3 times, spending an average of an hour each time working on the project. We had discussions on the design of the program and what part of the project we will be working on. We made sure to commit frequently throughout the week. I think that the way we organized ourselves was effective and allowed us to get the program done in a timely manner.
As for Google Project Hosting I found the Issues tab to be an effective way for members of a project to point out problems that arise during the course of the project. Probably the only annoyance I had with Google Project is the amount of emails I got. In the past week I received 40 emails from the project. I understand getting an email for rather important items like commit changes but wiki changes and some issue reports are things that I really don't need to know about. There should be some sort of priority on whether something is email worthy.
Wednesday, October 8, 2008
SVN With A Partner
Recently I worked on my partner's project using SVN. The first thing I did was Source->Format his code in Eclipse and made changes to his comment grammar. Then I changed the default output path to build/classes to bin. That should fix the same build issue that I also had in my project which I talked about in this blog post. Then I added more descriptions for his Javadoc comments on his methods.
Working Nicely With Others
Overall I learned how to work with other programmers using SVN. This was a good experience for me since only recently have I started to collaborate with another individual on a program. Before I was basically programming on my own. Without SVN I can see many unnecessary meetings where we would have to delegate responsibility over portions of code and spend wasted time resolving conflicts. Also without Ant I predict that the quality of the code would drop and people would get annoyed at their partners for making them do extra work because a change might have broken something in the program. With Ant it has made it easy to ensure that when I commit code to SVN, that code will run properly. In the future I would definitely use SVN and Ant with collaborative projects.
Having another individual look at my code helps to reveal mistakes I might have made or problems that I couldn't find a solution to no matter how much pound my head on the keyboard. There are times where I had a partner who was at the same place as I was in the assignment. Those times can be a good way to learn from someone else's mistakes especially during pair programming sessions in class.
Working Nicely With Others
Overall I learned how to work with other programmers using SVN. This was a good experience for me since only recently have I started to collaborate with another individual on a program. Before I was basically programming on my own. Without SVN I can see many unnecessary meetings where we would have to delegate responsibility over portions of code and spend wasted time resolving conflicts. Also without Ant I predict that the quality of the code would drop and people would get annoyed at their partners for making them do extra work because a change might have broken something in the program. With Ant it has made it easy to ensure that when I commit code to SVN, that code will run properly. In the future I would definitely use SVN and Ant with collaborative projects.
Having another individual look at my code helps to reveal mistakes I might have made or problems that I couldn't find a solution to no matter how much pound my head on the keyboard. There are times where I had a partner who was at the same place as I was in the assignment. Those times can be a good way to learn from someone else's mistakes especially during pair programming sessions in class.
SVN and Google Project Hosting
Subversion (SVN) is way for multiple developers to work on a project while minimizing conflicts. While not perfect, I think it's one of the best ways to manage a project, at least compared to the alternatives like RCS and CVS. For my project I used TortoiseSVN as my SVN client.
Using SVN
For the "Stack-Johnson" project located at http://code.google.com/p/stack-johnson/ I replaced the println in the catch blocks of the testIllegalPop and the testIllegalTop methods with assert. I didn't think it was right to have println that didn't do anything in those spots. I found it difficult looking for changes I could add to the code because it already passed verification previously.
Google Project Hosting
I also created my own Google Hosting Project at http://code.google.com/p/stack-johnzhou/. I had help from Aric West during the in-class lab setting it up. I had issues running verify.build.xml on my project, which I later corrected. It seems that the last time I worked on my project I was focused with getting 100% coverage with Emma so I wasn't too concerned with getting it to pass verification.
Discussion Group
I also created a discussion group for the project located here: http://groups.google.com/group/stack-johnzhou-discuss. I had issues with updates getting sent from the project to the discussion group until I found that I using stack-johnzhou-discuss@googlegroups.com for activity notification when I should have been using stack-johnzhou-discuss@google.com.
Using SVN
For the "Stack-Johnson" project located at http://code.google.com/p/stack-johnson/ I replaced the println in the catch blocks of the testIllegalPop and the testIllegalTop methods with assert. I didn't think it was right to have println that didn't do anything in those spots. I found it difficult looking for changes I could add to the code because it already passed verification previously.
Google Project Hosting
I also created my own Google Hosting Project at http://code.google.com/p/stack-johnzhou/. I had help from Aric West during the in-class lab setting it up. I had issues running verify.build.xml on my project, which I later corrected. It seems that the last time I worked on my project I was focused with getting 100% coverage with Emma so I wasn't too concerned with getting it to pass verification.
Discussion Group
I also created a discussion group for the project located here: http://groups.google.com/group/stack-johnzhou-discuss. I had issues with updates getting sent from the project to the discussion group until I found that I using stack-johnzhou-discuss@googlegroups.com for activity notification when I should have been using stack-johnzhou-discuss@google.com.
Wednesday, October 1, 2008
The Limits of Test Coverage
Having a partner for this program made it easier to sort through the issues that I was having, especially since my partner was farther along than I was. In this case my partner was Creighton Okada and from him I picked up on some of the assert methods that I should be using.
Adding Failure
In order to create a unit test that failed I added a method to the test code that will check the size of the array. I intentionally made it so the expected value was less than the actual size to make the test fail. When Emma was ran, it reported 100% coverage but when Junit ran the test code it failed.
Conclusion
This shows that there are limits to Emma. It appears that Emma only really checks whether the lines in the code is executed and not whether the test cases are actually valid. Pair programming helped me but I think it would've been better if we were both in at the same point in our progress.
The project can be found here.
Adding Failure
In order to create a unit test that failed I added a method to the test code that will check the size of the array. I intentionally made it so the expected value was less than the actual size to make the test fail. When Emma was ran, it reported 100% coverage but when Junit ran the test code it failed.
Conclusion
This shows that there are limits to Emma. It appears that Emma only really checks whether the lines in the code is executed and not whether the test cases are actually valid. Pair programming helped me but I think it would've been better if we were both in at the same point in our progress.
The project can be found here.
Using Emma to Improve Testing Coverage
When I was given this project the current coverage was at ~80%. As some point while working on it, eclipse was giving me errors on certain lines of code. Even after undoing the code back to the original it was still giving me the errors. It turns out that the project required that I went to Project->Clean in order to discard build problems.
Code Changes
In TestClearStack.java I added a line to test getTop(). I had issues with the isEmpty method until I found out that I had to test both true and false cases. For TestStack.java I added a test for toString. I had some difficulty parsing what was supposed to be outputted so I used a println to check. Then I added a test for the top method in case it threw a EmptyStackException.
Conclusion
I think that these changes improved the testing of the code. It's good to know that every line of code works as it's suppose to. It doesn't make a code foolproof though cause there can be elements in a program that one might not think of testing. 100% percent coverage may mean that you touch upon every line of code but it might not consider necessary features that might be missing or incidents that might cause errors.
You can find my build here.
Code Changes
In TestClearStack.java I added a line to test getTop(). I had issues with the isEmpty method until I found out that I had to test both true and false cases. For TestStack.java I added a test for toString. I had some difficulty parsing what was supposed to be outputted so I used a println to check. Then I added a test for the top method in case it threw a EmptyStackException.
Conclusion
I think that these changes improved the testing of the code. It's good to know that every line of code works as it's suppose to. It doesn't make a code foolproof though cause there can be elements in a program that one might not think of testing. 100% percent coverage may mean that you touch upon every line of code but it might not consider necessary features that might be missing or incidents that might cause errors.
You can find my build here.
Subscribe to:
Posts (Atom)