Replies: 2 comments
-
I wonder if it's worth starting with Node's built-in test runner while we're teaching the basic process: // demo.mjs
import assert from "node:assert/strict";
import { describe, it } from "node:test";
function add() {}
describe("add function", () => {
it("adds two and two", () => {
assert.equal(add(2, 2), 4);
});
}); Pros:
Cons:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Test-driven exercise that guides you step-by-step through initially ignored tests: https://github.com/textbook/tdb |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Thinking of weaving in a TDD theme across the whole syllabus, the skills that need teaching include:
Some decisions we might want to make (but might regret making?)
Specifically for "how to TDD" both need specific exercises/materials to teach/practice these concepts. A sample might look like this
TDD rules of engagement
We have two kinds of code:
We have a Red/Green/Refactor cycle
Let us solve the following exercise step by step
Step 1
Step 1 is "Red" (write a failing test). For each of the following determine if the tests are now passing or failing and explain whether this is an ok proposal for this step and why (not)?
a)
Answer:
Failing. This is ok. It is a good first failing test (maybe making the person exactly 18 would be better)Code being tested
Tests
b)
Answer:
Failing. This is ok. It is a good first failing test (it could be argued that the person argument and return false are not strictly needed in the code to be tested)Code being tested
Tests
c)
Answer:
Passing. This is not ok. The test passes instead of failingCode being tested
Tests
d)
Answer:
Failing. This is not ok. There are 2 failing tests (when you have more experience you might find that writing 2 tests instead of one is occasionally the best thing to doCode being tested
Tests
Step 2
Step 1 is "Green" (make the test pass). Assuming we start with answer a) from step 1, for each of the following determine if the tests are now passing or failing and explain whether this is an ok proposal for this step and why (not)?
a)
Answer:
Failing. This is not ok. The test fails instead of passingCode being tested
Tests
b)
Answer:
Passing. This is ok. The test now passesCode being tested
Tests
c)
Answer:
Passing. This is not ok. The test passes, but we have written too much code. This might not seem like a bad thing, but it is now not possible to write a failing test for a person under 18Code being tested
Tests
Step 3
Step 3 is Refactor. There is not much to refactor yet, so let's move on to Step 4.
Step 4
Step 4 is Red. Assuming we start with answer b) from step 2, for each of the following determine if the tests are now passing or failing and explain whether this is an ok proposal for this step and why (not)?
a)
Answer:
Failing. This is ok. This a good next failing testCode being tested
Tests
b)
Answer:
Failing. This is ok. But it's probably not the best next failing test as we have started our tests by working with a person's age (according to the written description)Code being tested
Tests
TODO: keep writing these until all the rules of engagement (described in the cycle above) are addressed
Building up to TDD
Trainees don't know where to start with TDD. In order to build up, we could create exercises (starting in JS1) where each step is one red/green (refactor), with the tests pre-written. Something like "Write a function to return the array of emails of people who work at Microsoft" becomes
return [persons[0].email]
but that's maybe good array practice?)The key is that each iteration continues to pass the tests previously run but has a slightly more complex solution.
Beta Was this translation helpful? Give feedback.
All reactions