Testing Project
Objectives:
- to think abstractly about how a piece of software might be implemented
- to gain experience with class invariants and method pre- and post-conditions
- to practice writing good tests
- to get experience using JUnit framework, including the strengths and limitations of unit testing
- To help you become a good, systematic tester!
Due: Before midnight on Wednesday, October 26.
Pair Assignment
This is a pair assignment.
Set up
Use Subclipse to checkout the project for your team's code. I
named your project with your team's name. Since you're only focused
on testing, I didn't create the trunk, etc.,
directories. Just checkout your project as a Java project.
The Car class defines a model of a car that can go forward or reverse, using appropriate amounts of fuel.
Notice that the Car's methods are stubs--they only
contain enough code to make Car compile. I have my own
version of this code with real method implementations. However, my code
is not perfect and contains faults.
Also notice the class invariants and pre- and post-conditions in the code. They clarify the natural language comments in the code.
Here is the (public) API for the
Car class.
Testing
Using JUnit, write test cases
for the Car class. Put your tests in a separate package,
as we did in class. Since you do not have code for the Car class, you
will have to imagine what that code might look like to write good
tests. You might find it useful to write code for the Car class if you
are having trouble imagining what the code might look like.
Goal: Create a set of good test cases that are likely to find errors in the code. Specifically, you want to be able to reveal the faults in my code. We've been talking about what it means for a test case and/or a set of test cases to be good, e.g., you want to automate the test case, cover all of the code/functionality and you want to test boundary cases, etc..
I'm not giving you the actual code because I don't want you to simply debug my code and write test cases that find those bugs. I want you to write test cases that will reveal ANY and ALL faults in the code.
Enjoy the challenge! How often does a professor ask the students to find and expose their faults?? :)
Analysis (30% - Individual)
In a text file or PDF (NOT a doc, docx, odt, or anything else), answer the following questions, clearly and concisely:
- How difficult was it to write test cases for this class? What made the process difficult? easy?
- Would it be more or less difficult for you to write test cases for a class that you had already written? Why? Try to think of at least one advantage and one disadvantage to testing your own classes.
- What could you do when writing your own classes to make testing easier? How could you make testing your classes easier for someone else?
- What do you think of the JUnit framework? How easy/difficult was it to write test cases using JUnit? How would the testing process go without JUnit? Did JUnit limit you in any way?
- Describe your process. What made the process easy? What made the process difficult? How would more or fewer people change the process?
- Approximately how much time did you spend on the project--in your pair and on your own? (Does not affect your grade in any way.)
Hints and Suggestions
| You ask: | My advice: |
|---|---|
| How do I start? | First, start early! Read through the code, start thinking about what needs to be done and then use a systematic approach to test everything. Think about the different classifications we talked about in class and implement those. You may want to create a checklist on paper of all the possibilities before you try to code anything. (If you need more help, please come talk with me.) |
| What do I do when the specification is ambiguous? | Make reasonable assumptions and document them in the tests--not the Car class because I use my own Car class. |
| How many tests should I have? How do I know I'm finished? | Ah, that is the tester's dilemma, isn't it? Use a systematic approach to make sure that you have covered all possibilities. Start early so you have time to come back to the project with a fresh mind to see if you may have missed something. |
| How should I organize my test methods/classes? | There are several different ways you could organize your test classes. (Note you CAN have multiple test classes for one "base" class.) You can categorize your tests into classes by functionality; by fixtures, e.g., preconditions or object state; by the set up required for the objects; by all pass or all errors. |
| How should I name my classes? | Name tests clearly and consistently. One suggestion is to name them
using the format: functionality_state_expectedresult
|
Submission
I have access to your team's repository, so everything in the repository will be graded. Make sure all of your code is in the repository.
Commit your analysis, named by your user name, in your repository.
Grading (6% of Final Grade)
You will be evaluated based on the following criteria (300 pts):
- Complete set of good test cases
- Ability of test cases to reveal faults
- Analysis of testing (30%)