The most challenging part of specification-based testing is identifying boundaries. They are tricky to find, given the way we write specifications. Luckily, they are much easier to find in source code, given how precise code has to be.
The idea of identifying and testing on and off points fits nicely in structural testing. For example, we can analyze the if
statements in the leftPad
program:
if
(pads
<=
0)
—The on point is 0 and evaluates the expression totrue
. The off point is the nearest point to the on point that makes the expression evaluate tofalse
. In this case, given thatpads
is an integer, the nearest point is 1.if
(pads
==
padLen)
—The on point ispadLen
. Given the equality and thatpadLen
is an integer, we have two off points: one that happens whenpads
==
padLen
-
1
and another that happens whenpads
=
padLen
+
1
.if
(pads
<
padLen)
—The on point is againpadLen
. The on point evaluates the expression tofalse
. The off point is, therefore,pads
==
padLen
-
1
.
As a tester, you may want to use this information to see whether you can augment your test suite.
We discussed the loop boundary criterion earlier, which helps us try different possible boundaries. If a loop has a less conventional, more complicated expression, consider applying on and off analysis there as well.
Leave a Reply