CS 160

Homework 3

First draft due date: October 16

Second draft due date: October 23

Final version due date: October 30

Note: Homework assignments are individual work, even when they relate to the project. You may discuss your assignments with each other, but the work must be yours alone.

Start this homework with QuickieQuiz from Lab 5. (I.e. the version before homework 2)

Problem #1.

Supply two JUnit 4.1 test classes, QuizTest and SubmissionTest. Each test class should contain two test cases that test aspects of the Quiz() and Submission(Person, Quiz) constructors (since these are the only nontrivial methods). In the javadoc comment of the test method, explain briefly what you are testing.

Place the test classes in the same package as the tested classes.

Supply a target run-tests in build2.xml that runs these unit tests.

Problem #2.

Fortunately, you can test a session bean without writing a web application. Injection won't work; you have to make an explicit lookup. Place this code into your test or @Before method:

InitialContext ctx = new InitialContext();
UserSB userSB = (UserSB) ctx.lookup(UserSB.class.getName());

The trick is to figure out the classpath that you need; it's your job to research that.

Your UserSBTest class should carry out the following tests:

• Find the admin user (which you expect to always be present)
• Add a non-admin user that isn't currently present (check first by calling getAllUsers). Verify that getAllUsers now lists it.
• Remove the admin user and verify that it is gone. Then put it back to ensure that future tests don't get messed up.

Note: GlassFish needs to run when you execute the test. You may assume that it will run when I execute your test.

Place the test class in the same package as the tested class.

The target run-tests in build2.xml should cause this test to be executed as well.

Problem #3.

Using the technique of mock objects, write a test class for UserMB. Supply a class MockUserSB that implements all methods of the UserSB interface, but without accessing any database. (Simply keep an ArrayList<User> in memory.)

Add a method setUserSB to the UserMB class. In the class UserMBTest, set the mock UserSB object. Then write test methods in UserMBTest that test these scenarios:

• Login as admin with the correct password, and check that the login succeeded
• Login as admin with an incorrect password, and check that the login failed
• Check that the getAllUsers method formats users with both first and last name, with only first name, with only last name, and without either first or last name correctly.

The target run-tests in build2.xml should cause this test to be executed as well.

Place the test and mock classes in the same package as the tested class.

Problem #4.

Use HTTPUnit to write a class com.horstmann.qq.test.AddUserTest that runs through the following scenario:

• Log on as administrator
• Add a new user
• Check that the user exists in the dropdown list of the “edit users” screen.
• Remove the user so that the test can be repeated
• Check that the user no longer exists

The target run-tests in build2.xml should cause this test to be executed as well.

Note that HTTPUnit is not trivial; be sure to budget sufficient time for learning it.

Note: You may want to change the IDs of forms and components so you can locate them through HTTPUnit.

Submission instructions

Your solution will consist of a file report.html in the root directory of your project, build2.xml and build2.properties, and all source files for the program, in the same layout as the QuickieQuiz project, and no unnecessary files (i.e. no .class, build, or dist directories). See http://www.horstmann.com/sjsu/fall2006/cs160/project-cvs.html.

You will check your solution into your individual CVS sandbox, as module hw3. I will check out your work with the following commands:

export CVS_RSH=/usr/bin/ssh
export CVSROOT=:ext:username@oslo.cs.sjsu.edu:/home/cvsroot/sandbox/username
mkdir -p ~/gradehw3/username
cd ~/gradehw3/username
cvs checkout hw3
cd hw3
cp ~/build2.properties build2.properties
ant -f build2.xml run-tests

My build.properties contains these three lines.

glassfish.dir=/usr/local/glassfish
junit.jar=/usr/local/junit4.1/junit-4.1.jar
httpunit.dir=/usr/local/httpunit-1.6.2

Yours should contain exactly two lines with the same keys, and with values that work for your system. Note that your file will be overwritten during testing.

You will want to try this yourself.

You will make at least three checkins at the dates given above. The first checkin must contain a solution to the (easy) problem #1. The second checkin must contain a solution to #2 (moderately hard) and #3. The final checkin must contain a solution to all problems, including the fairly challenging #4. Each checkin must contain an up-to-date report.html and a working. You are, of course, encouraged to frequently check in intermediate working versions.