Testing your program
A test compares what should happen with what actually happens. You decide the expected result first. Then you run the program with a particular example and compare the two.
Testing does not mean clicking around until nothing looks wrong. A useful test asks a clear question, such as “Do zero stars give zero points?”
Make a test table
Suppose each star is worth two points. Write three examples before coding:
| Stars | Expected points | Why try this? |
|---|---|---|
| 0 | 0 | Nothing collected |
| 1 | 2 | One collection |
| 5 | 10 | Several collections |
The pair of an input and its expected result is a test case. Keep these cases so you can use them again after changing the program.
Let Pliro compare results
This example uses a function: a named piece of code that returns a result. Read functions first if that is new to you.
# language: en
function points(stars):
return stars * 2
say points(0) == 0
say points(1) == 2
say points(5) == 10
== asks whether two values are equal. Each line reports whether the actual result matches the expected one.
Predict, then run
How many checks should succeed?
true
true
true
true means the comparison succeeded. false would mean that test found a mismatch. These messages are simple checks, not a special Pliro testing framework, and they do not automatically stop the program.
Your challenge
Temporarily replace stars * 2 with stars + 2. Predict which checks fail, then run it. Restore the correct calculation afterwards. This helps you check that your tests can actually notice a mistake.
A common mistake
Copying the program’s calculation into the expected answer can copy the same bug. Work out small expected answers independently, using fingers, counters, or paper.
Passing these three checks does not prove every possible input works. Add cases when you discover a new rule or fix a bug. Repeating old tests after a change is called regression testing.