CSC/ECE 517 Fall 2009/Buddi UnitTestRef

From Expertiza_Wiki
Revision as of 17:50, 12 October 2009 by Kanke (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Unit Test for Buddi

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.