Question 4 of 8: White-Box and Black-Box Unit Testing Techniques

Question 4: White-Box and Black-Box Unit Testing Techniques (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) White-box and black-box unit testing techniques

White-box (structural) testing derives test cases from a module's own internal logic/source code, independent of its specification. Basis path testing uses the module's cyclomatic complexity V(G) to derive a minimum set of independent execution paths through its control flow (Question 6 works a full example on fn_delete_element). Condition testing exercises the individual true/false outcome of each logical sub-condition inside a compound decision, rather than treating the whole decision as one black-box true/false. Data-flow testing selects paths according to where each variable is DEFINED and subsequently USED, catching anomalies (a use before any define, a define never used) that a purely control-flow-based technique like basis path testing cannot see. Loop testing targets simple, nested, concatenated, and unstructured loops specifically at their boundaries — zero iterations, one iteration, and many iterations — a class of case a single basis-path pass through a loop does not, by itself, guarantee is fully exercised.

Black-box (functional) testing derives test cases from a module's specification/interface, independent of its internal code. Equivalence partitioning groups the input domain into classes expected to be handled alike, so one representative value per class stands in for the whole class. Boundary value analysis targets the edges of those classes specifically, since off-by-one defects concentrate there (Question 5 works a full example). Cause-effect graphing and decision-table testing systematically combine several input conditions to catch defects that arise only from specific COMBINATIONS of conditions, which testing each condition independently would miss.

(b) Comparing and contrasting the techniques

At the white-box/black-box level: white-box testing guarantees a defined level of internal structural coverage (every independent path, every loop boundary, executed at least once) but is entirely blind to whether the specification was correctly implemented in the first place, since it never consults the requirements. Black-box testing checks conformance to the specification directly and needs no knowledge of internal structure, so it is far better at catching missing or wrongly-implemented functionality, but it can miss an internal path or loop boundary that a white-box pass would have caught, precisely because it never looks at the code. A thorough unit test plan applies BOTH to the same unit, as Questions 5 and 6 do below for two different units of the same overall program.

Within the white-box family itself, the four techniques are complementary rather than redundant: basis path testing guarantees every independent DECISION path is exercised at least once, but says nothing about a loop's boundary behaviour (zero/one/many iterations) — that gap is exactly what loop testing exists to close. Condition testing exercises each sub-condition of a compound decision independently, catching a wrong sub-condition that short-circuit evaluation could otherwise mask behind an unchanged overall decision outcome, which basis path testing's whole-decision-node view cannot detect. Data-flow testing is orthogonal to all three — it follows a variable's value rather than the control-flow graph, so it can find a defect (e.g. a variable used before it is ever assigned on some path) that none of the control-flow-based techniques are even looking for. Within the black-box family, equivalence partitioning alone under-tests the EDGES of each class; boundary value analysis specifically targets those edges, and the two are normally applied together (as in Question 5) rather than as alternatives.