ITEC325 unit tests

unit tests
a first PHP function

Review: server: String → String — er, “http packet containing a URL-string, plus possibly other info like user-agent and cookies, → an http packet containing the html-string of the requested resource ¹, plus other info like the http-response-code”.

Review: show the result of requesting hello-world_php.txt (result: hello-world.php).
The server, seeing the suffix “.php”, is configured (presumably) to run that file as a php program, and whatever that program prints is what the server sends back to the client.

SO: when our browser visits on hello-world.php, and we do a show-source, do we see the php program? NO! (Why not? Let's reread the above paragraph!)

Wait: So how am I displaying the source, if the server doesn't send you the program? For this one example, I happened to make a copy of the php file, and re-named it ending in “txt”. When requesting that file, the server did not consider it a php program and didn't run it; instead it just returned that filed. It looks funky; do a show-source and then tell me why the client is displaying the source-code in a very odd way.

video: a first php program: test cases (12m12s)

Task: the function blend: Given two words (like “smoke” and “smog”), we blend them to get “smog” — combine the first half of the first word, with the second half of the second word. (Linguists will want to break on syllables ² and so on; we'll be more simple-minded and just take half of each word, ignoring syllable-breaks.) Similarly, when we blend “motor” and “hotel” we get “motel”.

For any programming task (from 120 on up, including web programming), we start with test cases, which are runnable code.

In ordered to be considered a test-case, you must have:

The expected output.
The actual output (that is, actually call our function to see what it returns).
??? (to be revealed soon ³)

To make this runnable code, we can write:

echo "actual: ", blend("motor", "hotel"), "\n";
echo "expect: ", "motel", "\n";
    
echo "actual: ", blend("smoke", "fog"), "\n";
echo "expect: ", "smog", "\n";

video: stub and corner-case-tests (12m12s)

We'll first write a "stub" function solely so that we can run our tests (even if they all fail).

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

By reflex, remember to check unit tests that include:

kneejerk value to test	example for `blend`
`0`	n/a
a string of length 0, viz. `""`	`blend("moo","")`, `blend("","moo")`, `blend("","")`
`1`	n/a
a string of length 1	`blend("moo","a")`, `blend("a","moo")`, `blend("a","b")`; `blend("a","")`, `blend("","b")`
a negative number	n/a
a fractional number	n/a
both `true` and `false`	n/a
For boolean functions, an input that will return `true`	n/a
For boolean functions, an input that will return `false`	n/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 ⁴; Similarly, if the empty-string makes no sense for the problem, then you don't need to test it.

Note: Here's something beyond what we'll consider in this course, but in general it's worth realizing that one can compile a “big list of naughty strings”, for use in automated or manual testing.

Finally: In addition to these knee-jerk test cases, you'll of course test inputs pertinent to the particular funciton your write: 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.

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.

Only after our tests all run (and fail), do we write the actual code:
video: completing blend, and debugging (12m30s)

¹ Or if the requested resource was (say) in image-file, the http packet's payload would be the bits of the image-file. The payload is actually reponsible for includeing a “mime-type” statement to help the receiver understand how the payload's bits should be interpreted, but it's forgivable to think of the payload as just being the bits all the other meta-information as part of some-header-or-another, w/o worrying to distinguish http header info from other headers. ↩

² For example, see some examples on wikipedia. ↩

³ Okay, okay, here's the third component right now: A way to automatically compare the actual and expected outputs, so that we don't rely on having to manually scour output with a human eye. ↩

⁴ 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. ↩

This page licensed CC-BY 4.0 Ian Barland
Page last generated

Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu

unit tests a first PHP function

The order of unit tests

If you want more testing…

unit tests
a first PHP function