What we are building

The scheduling function. No screen. Numbers in, numbers out.

The request

Give it the rules from your plan, exactly as written in Lesson 2.5:

Create src/schedule.ts with a function called nextGap.

It takes the current gap in days and the student's answer,
which is one of "forgot", "hard", or "easy".
It returns the new gap in days.

Rules:
- "forgot" sets the gap to 1 day.
- "hard" multiplies the gap by 1.2.
- "easy" multiplies the gap by 2.5.
- The result is rounded down to a whole number of days.
- The gap is never less than 1 and never more than 365.

Also write tests for it.

Done when: npm test passes.

It will finish quickly, and everything will be green

The agent writes the function. It writes tests. It runs them. They pass. It tells you the
step is complete.

Do not go to the next lesson. Check it by hand first.

Check it against your own examples

Your plan in Lesson 2.5 listed worked examples. Use them. Work out each one on paper, then
run it:

Starting gap Answer Your plan says What the code returns
1 easy 2
10 hard 12
10 forgot 1
200 easy 365
1 hard 1

Fill the right-hand column by actually running the function.

What you are likely to find

The first row is the interesting one. A new card with a gap of 1, answered “easy”, gives
1 × 2.5 = 2.5.

Your plan says rounded down, so the answer is 2.

There is a good chance the code returns 3, because rounding to the nearest whole number
is the ordinary thing to do, and “round down” is an unusual instruction that is easy to read
past.

The last row is worth looking at too. 1 × 1.2 = 1.2, rounded down is 1. So a card you found
“hard” comes back tomorrow, the same as if you had forgotten it. Is that what you want? Your
plan says so. This is a place where the code is right and the plan is wrong.

Now the part that matters most

Look at the tests the agent wrote.

If the code rounds to the nearest number, the test almost certainly says the answer is 3
as well.

Read that again. The tests pass, and both the code and the tests are wrong, in the same
direction.

This happens because the same reader misunderstood the same sentence twice. Tests only
catch mistakes when they come from a different source than the code. When the agent writes
both, they agree with each other, and agreeing with yourself is not evidence.

Tests written by whoever wrote the code can be wrong in the same direction as the code.

This is the single most important idea in this module, and it is the reason Module 5 exists.

How to fix it properly

Do not just say “use round down”. Give it your examples as the tests:

The rounding is wrong. Rounded down means 2.5 becomes 2, not 3.

Replace the tests with exactly these cases, then make the code pass them:

  nextGap(1, "easy")    === 2
  nextGap(10, "hard")   === 12
  nextGap(10, "forgot") === 1
  nextGap(200, "easy")  === 365
  nextGap(1, "hard")    === 1
  nextGap(400, "hard")  === 365

Now the tests come from you, and the code has to meet them. That is a real check.

This is the same lesson as “show, do not tell” from 2.4, arriving where it does the most
good.

Commit

npm test
git add -A
git commit -m "Step 6: scheduling function with tests from the spec"

Try this before the next lesson

  1. Did your agent make the rounding mistake? Write down what it actually did.
  2. Add a test for nextGap(0, "easy"). What should happen? Does your plan say?
  3. Look at any test the agent wrote that you did not ask for. Is it testing behaviour you
    actually decided, or behaviour it invented?
PreviousNext