Gregory M. Kapfhammer

Lab One, Group One: Joseph Zumpella and James Clause

---

Junit;

Junit is a unit based testing framework. Basically this means that you write a test case or cases for each of the methods in the class that you want to test. You can either write these tests before or during or after you start to code the progam. Writing them before or during is a good way to make sure that you're thinking about your methods in the correct way. Writing them during also provides realtime feadback to how well you have implimented your tests. Writing them after is probaly the hardest way to go about unit testing but it is still possible but doesn't provide as many benefits as writing them before or during coding of the class. Junit also can not help you with seeing how well your program works over all or how well methods can interact with each other. Junit also has several interal feature that help you write good test suites. Because of the setup and teardown methods it is easy to re-initialize your test environment to ensure test independance. The suite method is also useful in running several tests at once or creating a set of test that will test several programs at once.

In testing the provided MySQLDatabaseAgent I encountered several things that make this class a difficult one to test. One of the major problems is that the agent does not have a method to reverse the changes it has done automatically. In a future verison it might be beneficial to have a method that will roll back all changes to the database from a specific marker point. This would help ensure that testcases are always run on uniform environment. This might also be useful for customer funcionalty as well. The agent also sometimes has confusing variable names for arguements to its functions. This makes it hard for the tester to be sure that they are calling the functions with the correct arguments. Also it might be better to return an object that can give more information to the tester instead of just true and false. This would allow the tester to write test cases for more specific instances if he or she knows a little more about how the methods accomplish thier goals.

Jim Clause

---

Lab Notebook:

---

The biggest problem that I ran into was classpaths. I was very unfamiliar with all of the classpath and environment material, but Jim helped me through most of it. I didn't know too much about my .cshrc file. I added a few new set path and setenv lines to get junit and Jwhich to work. I didn't know some of the unix commands, but I learned that I can look them up by typing "man". After the adjustments we didn't have too much trouble setting up Jwhich, javap, or junit 3.7. I thought the coding and test cases that we came up with were relatively simple. We did have to make a setup and a tear down method so that we could run each test on each method independently and keep them from running together. We also created a test suite method to run all of our tests at once. I thought that Junit proved to be more helpful than I thought. It seems like a very good idea to test the methods as you work. The testing altogether is easier this way, due to the fact that you don't have to fix 50 errors the first time you compile. It also ensures that your test cases are correct as well since they should fail first. I also learned the command to run a Swing-based test: java junit.swingui.TestRunner [testcase].This is helpful to remember. Joe Zumpella

---

Link to this Page

• Laboratory One: Simple Software Development Tools last edited on 29 August 2002 at 1:43 pm by 141.195.35.147