CSC/ECE 517 Fall 2009/program2 buddi wn
Buddi Project
Objectives
- Verify that splits in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
- Refine and complete the view layer, and verify that it works as desired in all cases.
Bugs or Undesired Behaviors
| Title | Details | Actual Behavior | Expected Behavior | Solved |
|---|---|---|---|---|
| Create New menu | Undesired behavior. Create new options shouldn't be put under Edit menu. It's not intuitive for new users. | Under My Accounts tab, Edit -> Create Account. Under My Budget tab, Edit -> Create Budget Category. | Several options:
1. Move to under File menu 2. Create button for "New Account" and "New Budget Category" |
No |
| The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount. | No |
Unit test
CORRECT Boundary Conditions
Many bugs in code occur around "boundary conditions," that is, under conditions where the code's behavior may be different from the normal, day-to-day routine.
For instance, suppose you have a function that takes two integers:
public int calculate(int a, int b) {
return a/(a+b);
}
Most of the time, this code will return a number just as you expect. But if the sum of a and b happens to equal zero, you will get an ArithmeticException instead of a return value. That is a boundary condition—a place where things might suddenly go wrong, or at least behave differently from your expectations.
To help you think of tests for boundary conditions, we'll use the acronym CORRECT:
- Conformance — Does the value conform to an expected format?
- Ordering — Is the set of values ordered or unordered as appropriate?
- Range — Is the value within reasonable minimum and maximum values?
- Reference — Does the code reference anything external that isn't under direct control of the code itself?
- Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
- Cardinality — Are there exactly enough values?
- Time (absolute and relative) — Is everything happening in order? At the right time? In time?
Let's look at each one of these in turn. Remember that for each of these areas, you want to consider data that is passed in as arguments to your method as well as internal data that you maintain inside your method and class.
The underlying question that you want to answer fully is:
What else can go wrong?
Once you think of something that could go wrong, write a test for it. Once that test passes, again ask yourself, "what else can go wrong?" and write another test, and so on.