Isolating the Proctor’s Boundary Concerns

In many ways, our proctor is the most significant testing challenge in this course. We have a scheduler that depends on concepts of both mutability and time, ideas that are generally kryptonite for tests.

Properties of our proctor that make testing difficult

The scheduler has three events:

• Schedule

• Start quiz

• Stop quiz

Each of the above ideas is important. Our tests could wait, using sleeps, as our quizzes cycle through their respective states. That strategy would make our tests both fragile and slow, though.

Sleeps in tests are inherently suboptimal:

• Wait too long, and our tests are slow.

• Don’t wait long enough, and our tests won’t be consistent.

To prevent race conditions and timing-dependent code, we’ll need to find a better approach.

Our testing plan

Here’s our plan:

• Let’s modify our code to allow custom notifications when important things happen. Namely, when a quiz starts and finishes.

• Our tests can then await an event instead of sleeping for some specific amount of time.

The bonus is that by building in this new feature, our project will be improved as a whole, as it’s precisely the kind of feature that user interfaces will need to keep our customers informed. In detail, this is what we’ll do:

• Add an optional process ID to Mastery.schedule_quiz.

• Modify the proctor to accept this new argument.

• Notify the specified process when a quiz starts.

• Notify the process when a quiz stops.

When we are done, our tests will be much simpler. All they will need to do is await these specific messages as they work their way through the test.

---