Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2018 (3 hours, open book, 8 questions of equal value; the first FIVE as they appear in the answer book are marked — all eight are solved here as a study resource).
Traditional functional (black-box) unit testing treats the unit — classically a single procedure/function/module — as a box whose interface is exercised with input/output test cases designed by equivalence partitioning, boundary-value analysis and decision-table techniques, without regard to the internal code.
Object-oriented unit testing enlarges the "unit" from a single operation to the class, because a class's operations are encapsulated together with, and mutate, shared state. Testing a single method in isolation from the object's state and from the collaborator objects it calls is rarely sufficient, so OO unit testing designs test cases around the class's responsibilities and its interactions with the small cluster of classes it depends on.
State-based testing models the unit's behaviour as a finite set of states with events causing transitions between them (typically drawn as a state-transition diagram/table first), then derives test cases to exercise every state, every valid transition, and — importantly — every invalid transition the unit should reject or ignore.
Part (b) — comparing the three techniques. Traditional functional testing is the cheapest to design and works well for stateless, procedural units, but it is weak against encapsulated, history-dependent behaviour: a method can return the "correct" output for a given input in isolation yet still be broken with respect to the object's state, and functional testing alone will not notice. Object-oriented testing addresses this by widening the unit under test to the class and its immediate collaborators, which finds integration-like defects earlier (at "unit" test time) but is correspondingly harder to fully isolate — a class can rarely be tested with total independence from the objects it collaborates with, so test doubles/stubs are usually required. State-based testing is the most targeted of the three: it is the only technique of the three that explicitly checks behaviour that depends on the unit's history (has this object already been initialized/closed/committed?), which neither plain functional testing (which treats each call independently) nor generic OO testing (which may exercise states only incidentally) is guaranteed to cover. In practice the three are complementary rather than competing: OO unit testing typically incorporates functional test-case design for each operation and state-based test-case design for the class's lifecycle, because a purely functional view of an object's methods cannot confirm that invalid state transitions are correctly rejected.
