Test With Fake Connections

Join, registry and broadcast work, and so far only the demo and Submit have shown it. This lesson has you write tests of your own in tests/test_scoreboard.py, and run them in the terminal. The message test stays for the rest of the course; the three server tests describe version one of the scoreboard, and Chapter 8 replaces them. None of them opens a socket or starts a thread: each one hands the server a stand-in connection and checks what the stand-in recorded.

A stand-in, read from the demo

Open scoreboard_demo.py and find demo_connection. It builds a stand-in from three functions defined inside it, recv, send and close, which share one dict called state. send parses each message and appends it to state["sent"], or raises ConnectionClosedError when the stand-in was made with fail_send=True. The three functions are then collected, with an id and a request, into a types.SimpleNamespace, an object whose attributes are whatever you pass it. The server calls connection.send(...) and connection.id on it exactly as it would on a library connection, and never knows the difference. Python in Practice built stand-in sessions the same way.

The tests need less than that. add_viewer, apply_score and broadcast only ever use id and send, so make_connection(conn_id, *, fail_send=False) can be small:

def make_connection(conn_id, *, fail_send=False):
    sent = []

    def send(text):
        if fail_send:
            raise closed_error()
        sent.append(json.loads(text))

    return types.SimpleNamespace(id=conn_id, send=send, sent=sent)

closed_error() is supplied at the top of the file: it builds the ConnectionClosedError a send raises when the viewer’s connection ended without a close frame. Putting sent on the stand-in lets a test read viewer.sent afterwards.

Four tests

Each test follows the same three steps: arrange a board and some stand-ins, act through one call to the server, and assert what the stand-ins recorded and who is in board["viewers"].

• test_a_viewer_gets_the_board_when_it_joins: make a board, change its version and one team’s points, call add_viewer, and assert that the stand-in recorded exactly that snapshot and that its id is in the registry.

• test_a_score_reaches_every_viewer: add two viewers, apply one score, and assert that both received the new version and points.

• test_a_failed_viewer_is_dropped_and_the_rest_still_hear: register a viewer made with fail_send=True before a working one, apply a score, and assert that the failed one has left the registry and that the working one still received the update. The order matters: a failed viewer registered last could not show whether the loop went on after it.

• test_parse_message_refuses: keep the @pytest.mark.parametrize line, the one you met in Chapter 3, and give it at least three texts that parse_message must refuse. The true points case is already there. Inside, call parse_message in a try; return from except ValueError:, and after the try statement write assert False, ... with the text, so a text that is accepted fails the test.

To put a stand-in in the registry without a join snapshot, assign it directly: board["viewers"]["broken"] = broken.

Why through the module

The file imports the modules, import scoreboard_server and import scoreboard_messages, and the tests call scoreboard_server.apply_score(...). Keep it that way. Check my work runs your tests against versions of the server that each have one mistake, swapping the function in the module while your tests run, to see whether your tests notice. A call through the module looks the function up at the moment of the call, so it gets the swapped one. A name imported with from scoreboard_server import apply_score was bound once, when the file was imported, and keeps the old function. For the same reason, make every call inside a test function, not at the top of the file.

Run them

This lesson uses the terminal. Run the tests from the project folder:

python -m pytest -q

Each placeholder fails until you replace it. On the site, the finished file reported 8 passed: three tests, and five texts in the parametrized one, each counted as a test of its own. The demo still runs as before, and its output has not changed since Lesson 4:

python scoreboard_demo.py

These tests prove what one thread sees: the join snapshot, the broadcast and the removal of a gone viewer. They do not prove the race at the door from Lesson 3, which needs two threads at exactly the wrong moment. That one was proved by an instrument of the check’s own when you pressed Submit in Lesson 3; your tests do not have to.

When every test passes, press Check my work. The next lesson writes the scorekeeper’s handler, the last piece of scoreboard v1, and runs it with several viewers on 127.0.0.1.