Get the answers first
Imagine your teacher gives you the quiz answers before you study. You know exactly what to learn. You stop when you can answer everything.
Some developers work like this. They write the test first. Then they write the code. They stop when the test passes.
Key words
| Word | What it means |
|---|---|
| Unit test | A small test that checks one small part of the code. |
| TDD | Test-driven development. Write a failing test first, then the code. |
| Refactoring | Making code cleaner without changing what it does. |
| BDD | Behaviour-driven development. Describe the wanted behaviour in plain words before coding. |
| Behaviour | What the software does when a user does something. |
| User story | One need of a user, written in one sentence. |
| Acceptance criteria | The checks that tell you the behaviour is done. |
| Requirement | Something the software must do. |
| Business value | The good a behaviour brings to the customer, such as saving time or money. |
The cells students fill in are left blank in this preview.
Test-driven development
With TDD, each new feature starts with a test. The test says what the feature must do.
At first the test fails. That is good. It proves the test can fail. Then you write just enough code to make it pass.
Developers call a failing test red and a passing test green.
Quick check: the cycle
Have a go
Quick check: the cycle
3 questionsYour answers are marked here and are not kept. A college account keeps every student’s marks.
Try it: make the tests green
def double(n):
return n + 2 # this is wrong
def run_tests():
assert double(4) == 8
assert double(0) == 0
assert double(10) == 20
print("All tests pass: green")
run_tests()
# Run it. You see red: an error. Fix double() and run again.
Small steps
data-callouts.tip.label
Write only one test at a time. Write only enough code to pass it. Small steps find mistakes while they are small and easy to fix.
Behaviour-driven development
BDD starts one step earlier. Before any test, people talk about the behaviour the user needs.
Customers, testers and developers all write the behaviour in plain words. Every behaviour must have business value. It must also link to a requirement.
Later, each behaviour becomes a test.
A behaviour specification
| Part | What to write | Example |
|---|---|---|
| Title | A short name for the behaviour | Student buys a day ticket |
| Narrative | As a (who), I want (what), so that (why) | As a student, I want a cheap day ticket, so that I save money |
| Acceptance criteria 1 | Given (start), when (action), then (result) | Given I have a student card, when I choose a day ticket, then the price is 2 pounds |
| Acceptance criteria 2 | Given (start), when (action), then (result) | Given I have no student card, when I choose a day ticket, then the price is 3 pounds |
The cells students fill in are left blank in this preview.