RU beehive logo ITEC dept promo banner
ITEC 325
2015spring
ibarland

home—lects—hws
D2L—breeze (snow day)

corner-cases-and-implement-blend
test-cases
routine corner cases

By reflex, remember to check unit tests that include:

kneejerk value to testexample for blend
0n/a
a string of length 0, viz "" blend("moo",""), blend("","moo"), blend("","")
1n/a
a string of length 1 blend("moo","a"), blend("a","moo"), blend("a","b"); blend("a",""), blend("","b")
a negative numbern/a
a fractional numbern/a
both true an falsen/a
For boolean functions, an input that will return truen/a
For boolean functions, an input that will return falsen/a
a “typical” input.blend("abcd","xyz")
Of course, these are all subject to “if the input makes sense for the function”; if a function expects a natural number you1 don't need to test negative or fractional inputs. Similarly, if the empty-string makes no sense for the problem, then you don't need to test it.

In addition, you'll test cases pertinent to the code: A function dealing with names may want to check hyphenated-names, reasonably long names, short names (one letter). A function dealing with different tiers of prices (less than $25, less than $100, and above) should include cusps ($24.99, 24.995 (if possible), $25.00, $25.01, and so-on). For blend, we realize that even-length and odd-length are treated differently, so w/o much thought I'd toss in: 

      blend( "abcdef", "wxyz" ) // expect "abcyz"
      blend( "abcdef",  "xyz" ) // expect "abcz"
      blend( "abcde",  "wxyz" ) // expect "abyz"
      blend( "abcde",   "xyz" ) // expect "abz"
Arguably, checks above involving the empty string and strings-of-length one already cover all these cases. In this situation, I'd agree: I'd think ahead and anticipate that I don't have any if statements that handle even/odd differently (it'd all involve just integer-division-by-two), so I'm okay w/ omitting tests that just use different even/odd-length strings. This is “white-box testing”, where I consider the actual code. But if I have no clue what the code looks like (“black-box testing”), or the code might evolve in the future to involve an if for very-short strings, then the test cases of lengths 3-6 are important again. I find it easier to toss them in by rote, than to reason/guess about the possible code in possible futures.

Here is the full file, and the result of running it (show-source).

Conventionally, it's good to have the easiest/shortest/most-trivial tests first (involving 0, the empty string, etc.) — if one of them fails/crashes, they're the simplest to hand-trace and figure out what's happening. (Recall the first attempt at blend, where tests returned 0 (because we used + to concatenate instead of .); it's easier to trace through arithmetic of substr( "", 0, strlen("")/2 ) than substr( "Christiansburg", 0, strlen("Christiansburg")/2 )!

We've only mentioned unit tests; for more ways to reduce the bugs in your code (and the amount of time you spend banging your head on the wall), I recommend ITEC 335, Software Testing.


1 A type-safe language should catch this sort of error; if using a non-type-safe language, or one with liberal auto-type-coercion, then Turing help you. …You might add macros or pre-processing to your source code, to catch type errors in this case. For our class, using php (with dangerously liberal auto-type-coercion), we'll ignore this, since it's not in the scope of a web-programming class. This requires extra vigilance on you as a programmer, to be sure you're providing the right types.      ↩

home—lects—hws
D2L—breeze (snow day)

©2014, Ian Barland, Radford University
Last modified 2015.Jan.23 (Fri)		 Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu		 Rendered by Racket.