20 Questions: Software Testing Edition!

Up until now, we have been providing you with pre-written tests that you've been using to check that your code works correctly. But a big part of software development is writing tests. Therefore, starting in HW5, we will no longer be providing complete test suites: you will be expected to write most, or even all, of the tests yourself! Writing good tests requires some practice and getting into the right mindset, so today's lab activity is meant to give you some experience with this...in the form of a (hopefully) fun game you'll play with your partner!

This activity should be done together with your partner; however, unlike usual, you must make sure you're on SEPARATE computers, as the game requires that you can't see your partner's screen!

Getting set up

First, pick one partner to be "odd numbered" and the other to be "even numbered". (We don't really care how you do this, maybe just flip a coin?)

Now, the ODD partner should (on their OWN computer) connect to the CS 70 server and open the following directory: /cs70/spring2026/lab/testing-game/ODD (you can either open it in VS Code or just cd to it in the terminal). At the same time, the EVEN partner should do the same thing but replace "ODD" with "EVEN" (so you're opening /cs70/spring2026/lab/testing-game/EVEN).

Each partner should now see two files in the directory they just opened:

• your-code.cpp contains C++ code defining a simple function, with a comment explaining what the function does.
• your-partners-code.md contains a written description of YOUR PARTNER'S code (which is the same as the comment at the top of their version of your-code.cpp).

These are the ONLY two files you are allowed to refer to while playing the game. In particular, you are NOT allowed to look at your partner's files (which have the same names but are different from yours!).

Now, in total silence (no conspiring with your partner or other teams!), take a few minutes to introduce a subtle bug into the function you got in your-code.cpp. Note that your-code.cpp is read-only, so VS Code might not actually let you type in it; you can just write down your bug on a piece of paper, or in a separate file, etc.

You should notify your partner once you're ready. Once both partners are ready, follow the instructions below to play the game!

Playing the game

The game is a variation on 20 Questions and is played in two rounds.

In the first round, the ODD player takes the role of the tester and the EVEN player takes the role of the coder. Here are the rules:

• The tester should come up with inputs to give to their partner (e.g., they can ask their partner "run your function on the vector [1,2,3]")
• When the coder gets an input from their partner, they should run that input through the bugged version of their code (that they came up with earlier) and reply with what the function returns.

Victory conditions:

• The tester's goal is to guess the bug in their partner's code, based ONLY on the results they hear back for each input.
• If the tester thinks they know what the bug is, they can ask their partner, who should reply whether or not the guess was correct (you should be reasonably generous here, the description of the bug only needs to be conceptually correct, they don't need to guess the exact syntax character-by-character!)
• If the tester guesses correctly, they win the round. But they can only offer a total of 20 inputs. If they use up all 20 inputs without guessing the bug correctly, the coder wins the round.

When the first round ends, play a second round with the roles swapped (so ODD becomes the tester and EVEN becomes the coder).

Post-game reflection

Believe it or not, the structure of this game is a lot more similar to "real" testing than you might expect! Just like in the game, in "real life" you'll often be writing tests for code that you haven't seen, with only an interface specification as reference. In the game this was because the code was hidden from you...but in real life (and in your homeworks) it's because the code literally doesn't exist yet. Indeed, the entire premise of test-driven development is that we write tests first, and then write the code (so that we can use the tests to validate the code).

So how do you come up with test cases for code that you haven't seen? Exactly the same way you came up with inputs to give to your partner! Based on the interface specification, you think of what you expect the function to return for specific inputs, and you consider not just "ordinary" inputs but also edge cases that might intuitively be tricky. It's really more of an art than a science though, so why don't you tell us a bit about your thought process?

(When logged in, completion status appears here.)

Previous Page Go to Parent Page