RU beehive logo ITEC dept promo banner
ITEC 325
2017fall
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 and 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”; you don't need to test negative or fractional inputs if they are nonsensical for the problem at hand 1; Similarly, if the empty-string makes no sense for the problem, then you don't need to test it.

Here's a “big list of naughty strings”, for use in automated or manual testing.

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).

The order of unit tests

Put your trivial test-cases first. (That is, the ones 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.

Suppose, in writing blend, all our tests return 0 (?!). It's easier to trace through arithmetic of substr( "", 0, strlen("")/2 ) than substr( "Christiansburg", 0, strlen("Christiansburg")/2 ). And in particular, we'd find out that "" + "" returns 0, and that would make us realize that we should use . for string-concatenation, in php.

The one exception is if you're also using your tests for documentation. Having one typical-use case (or two or three) is extremely effective at helping readers understand what your function does. (In full frameworks, your documentation and test systems should share info, but in quick-and-dirty settings, then your first couple of test cases might double as example-documentation.

If you want more testing…

We've only mentioned unit tests, and that's all we'll focus on for our code. However, there are many more approaches to testing, which all help 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 (like php), 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)

©2017, Ian Barland, Radford University
Last modified 2017.Sep.01 (Fri)		 Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu		 Rendered by Racket.