Question 5 of 8

Question 5 (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.

Part (a) — when black-box unit testing is preferable. Black-box testing is preferable at the unit level when:

• The unit's internal implementation is unavailable or irrelevant to the tester — e.g. testing a third-party library, a generated/compiled component, or code the tester did not write and should not need to read.
• The goal is to validate against the specification/interface contract rather than the code's internal paths — confirming the unit does what its documented contract promises, independent of how it is implemented (so the tests remain valid if the implementation is later rewritten).
• The unit's internal structure is very complex or opaque (e.g. a compiled DLL, an ML model, obfuscated code) and deriving/tracing internal paths (white-box) is impractical, but its input/output behaviour is well specified.
• Testing must be done by someone without programming access to the unit — a domain expert or end user validating behaviour against requirements they understand, without needing to read source code.

Part (b) — equivalence partitioning. Equivalence partitioning divides a unit's input domain into classes ("partitions") of data such that, if one representative test value from a class reveals a defect, every other value in that class is assumed to reveal the same defect (and if one value passes, the class is assumed to pass) — this lets the tester replace an infeasibly large input space with a small, representative set of test cases while retaining (assumed) full coverage of distinct behaviours. It is a black-box technique — classes are derived purely from the specification of valid/invalid input ranges, never from the code. One important case: a numeric input field specified as "accepts an integer discount percentage from 0 to 50" naturally partitions into {valid: 0-50}, {invalid: negative}, {invalid: >50}, and {invalid: non-numeric} — testing one representative value from each of these four classes (rather than exhaustively trying every integer) is exactly what makes exhaustive-input testing of even a small numeric range practical, and it is the same technique used to build Q7's login/password test suite.

Part (c) — two white-box techniques, and which is most useful. Basis path testing (McCabe) derives V(G) independent test paths from a unit's control-flow graph, guaranteeing every statement is executed at least once (used in Q8). Condition/branch testing derives test cases that force each individual condition in a decision (and each decision's true/false outcome) to be evaluated both ways at least once, which catches logic errors basis-path testing alone can miss when a decision has compound conditions (e.g. if (a && b)). Of the two, basis path testing has been the most useful over the past decade, because it is directly automatable: modern static-analysis and coverage tools compute V(G) and generate/measure basis-path (branch) coverage automatically as part of continuous integration, giving teams an objective, tool-reported minimum-test-count target on every commit — a level of automation and continuous applicability condition testing (which needs a human to enumerate compound-condition combinations) has been slower to reach at the same scale.