PE Software: Software Construction

What this domain tests

Construction covers detailed design, coding, unit testing, integration, and the mechanics that turn a design into working, maintainable code. Expect defensive programming, complexity metrics, review effectiveness, refactoring discipline, and integration strategy.

Core rules and concepts

• Defensive programming: validate inputs at trust boundaries, fail fast on invalid state, never silently swallow exceptions, and distinguish recoverable errors from programming defects.
• Coding standards reduce defect density mainly by removing arbitrary variation; inspections and code review find defects far earlier and cheaper than system testing does.
• McCabe cyclomatic complexity for a control flow graph: M = E - N + 2P, where E is edges, N is nodes, and P is the number of connected components. For structured single-entry code this equals decision points + 1.
• M gives the number of independent paths through the code, which is the minimum number of tests for basis-path coverage. Commonly cited guidance treats M above roughly 10 as high risk and a candidate for splitting.
• Refactoring restructures code without changing observable behavior. It is not a vehicle for adding features, and it needs the safety net of automated tests.
• Integration order: big-bang, top-down (needs stubs), bottom-up (needs drivers), sandwich. Continuous integration means building and testing every commit against a shared mainline.

Worked example

A function's control flow graph has 9 edges, 7 nodes, and forms one connected component. M = E - N + 2P = 9 - 7 + 2(1) = 4. Interpretation: there are four linearly independent paths, so at least four tests are needed for basis-path coverage. Cross-check by counting decisions: the source has three if statements with no else branches and no loops, so M = 3 + 1 = 4. The two methods agree, which confirms no edge or node was miscounted in the graph. Assessment: M = 4 is comfortably low risk; the module needs no split on complexity grounds, and the four paths define a concrete unit test set.

Traps that cost marks

• Counting an else as an additional decision; only the branch condition adds decision points.
• Forgetting the 2P term when the graph has disconnected components.
• Treating cyclomatic complexity as a standalone quality score; a simple function can still be wrong.
• Confusing a driver (test harness calling the module under test) with a stub (stand-in for a called module).