Test behaviour and read diagnostics

A pass-rule program can compile and still use the wrong boundary. Tests compare actual behaviour with stated expectations, especially at edges. Compiler diagnostics concern source rules; failing tests concern behaviour that did not meet an expectation. Separating them makes debugging more systematic.

For a package, Swift Testing offers @Test and expectation macros on supported toolchains; XCTest is also available. The small complete example below uses precondition for an executable check, not as a replacement for a test suite or input validation.

Save this complete program as main.swift and run it with the Swift toolchain. No separate input file is needed.

Swift · complete program

func passed(_ score: Int) -> Bool { score >= 75 }
let checks = [(74, false), (75, true), (80, true)]
for (score, expected) in checks {
  precondition(passed(score) == expected)
}
print("3 boundary checks passed")

Expected output

3 boundary checks passed

Follow the execution

The three checks cover below, exactly at and above the threshold. If one comparison fails under this checked build, execution stops rather than printing the success message. The tests are tied to the stated rule, not simply copied from an implementation’s arbitrary output.

Try this program in the Swift compiler. Paste the complete source above.

Your task: Which check catches changing >= 75 to > 75?

Swift · complete program

func passed(_ score: Int) -> Bool { score >= 75 }
let checks = [(74, false), (75, true), (80, true)]
for (score, expected) in checks {
  precondition(passed(score) == expected)
}
print("3 boundary checks passed")

Worked answer

The input 75 with expected true catches the mistake. That is why a boundary example can be more informative than many scores far from the threshold.

Precondition is not an appropriate mechanism for validating untrusted form data, and optimization modes affect some runtime checking mechanisms. Use configured tests for regression protection, and errors or explicit results for ordinary invalid inputs. Read the first relevant diagnostic before changing unrelated code.

The input 75 with expected true catches the mistake. That is why a boundary example can be more informative than many scores far from the threshold. Precondition is not an appropriate mechanism for validating untrusted form data, and optimization modes affect some runtime checking mechanisms.

Further reading: official Swift language guide.