3.2.11 - Test data and program refinement (C#)

Testing against expected behavior

Testing checks an algorithm or program against its requirements using chosen inputs and expected outcomes.

Running without an error does not show that the result is correct. First state what the program should do, calculate the expected outcome independently, then compare it with actual behaviour. For a ticket-cost function, three £4 tickets should cost £12; a result of £7 would reveal a fault even if the program runs normally.

A test table can add actual outcome and pass/fail after running. An expected result taken from the faulty program itself would make the test circular. Test different important paths, such as accepted and rejected input, rather than repeating many similar successful cases. Tests increase confidence and reveal faults; a few passes cannot prove the absence of every fault.

Designing, writing, testing and refining textual programs develops practical programming skill. Schools and colleges separately confirm that students have had the required opportunities through their practical programming statement. This NovaLearn practice neither certifies centre authentication nor supplies an assessed NEA project.

Normal, boundary and erroneous data

Different categories of test data probe ordinary use, acceptance limits and invalid input, so each selected value should have a specific purpose.

For a game's permitted score range 1–10 inclusive, use this plan:

Normal data is typical valid data. Boundary data tests extremes on both sides of the allowed limits, not only the two valid endpoints. Erroneous data violates a requirement; 0 and 11 are also erroneous here, so categories can overlap. The exact values depend on the rule, not a memorised universal list.