🏆Eindproject: Bewijs het met tests

De server en de client houden zich elk aan hun helft van het contract, en tot nu toe is het enige bewijs Check my work en de transcripten van pl_ws.py. Een project dat je aan iemand anders overdraagt, heeft een eigen bewijs nodig: tests die met één opdracht draaien en zouden merken als een regel brak. Een regel die niemand test, is een regel die de volgende verandering kan breken zonder dat iemand het ziet.

Niets in deze les opent een poort, start een thread of wacht op een klok. Elke test roept je functies direct aan met stand-ins, draait in milliseconden en geeft elke keer hetzelfde antwoord.

De stand-ins die je krijgt

tests/test_scoreboard.py bevat al twee hulpfuncties. make_connection(conn_id) is de stand-in-kijker uit hoofdstuk 7: een object met een id waarvan de send elk bericht, geparset, vastlegt in zijn lijst sent. headers_with(*values) bouwt verzoekheaders met één Authorization-regel per waarde, zoals de bibliotheek ze bouwt, zodat check_request ze kan lezen met get_all.

tests/test_client.py bevat er drie. snapshot(version, owls) geeft de JSON-tekst terug van een snapshot met één team. connect_to(messages, calls) geeft een stand-in terug voor de connect van de bibliotheek: de verbinding ervan deelt messages één voor één uit en werpt daarna de close met 1000 op die de bibliotheek zou opwerpen, en hij legt de opties vast waarmee connect werd aangeroepen en elke verstuurde score. Hij geeft contextlib.nullcontext(connection) terug, wat het with-blok van de client iets geeft om binnen te gaan dat de stand-in teruggeeft. refused_with(status) geeft een connect terug die InvalidStatus opwerpt voor die status, zoals de bibliotheek doet als een server de handshake weigert.

Er komen er nog twee van pytest zelf: noem een parameter van een test capsys en pytest geeft een object mee waarvan readouterr() teruggeeft wat de test tot nu toe afdrukte, als out en err; noem hem tmp_path en je krijgt een verse map voor bestanden die de test schrijft. Je kwam ze allebei tegen in Python in Practice.

Vijf tests

Elke test zet een bord of een stand-in klaar, handelt één keer, en controleert wat het contract zegt. De test voor binnenkomen, bijvoorbeeld:

def test_a_new_viewer_starts_with_the_whole_board():
    board = scoreboard_server.make_board(["Owls", "Foxes"])
    scoreboard_server.apply_score(board, {"type": "score", "team": "Owls", "points": 4})
    outbox = scoreboard_server.add_viewer(board, make_connection("v1"))
    first = scoreboard_server.take(outbox)
    assert first["version"] == 1
    assert first["scores"] == {"Owls": 4, "Foxes": 0}

De andere vier, in woorden:

• Broadcast. Voeg twee kijkers toe, verwerk één score, en controleer dat take op elke outbox de nieuwe versie geeft. Met één kijker kon een broadcast die te vroeg stopt het niet laten zien.

• Weigering. Roep check_request aan voor /score zonder token en met een verkeerd token, die elk 401 geven; met het juiste, dat None geeft; en voor /watch zonder token, dat None geeft.

• Verouderd. Draai scoreboard_client.main(["watch", "--url", ..., "--max-messages", "5"], connect=...) via connect_to met versies 3, 2, 3, 4, en controleer dat er precies twee regels werden afgedrukt, voor 3 en 4, en dat het 0 teruggaf.

• Een geweigerd token. Schrijf een token naar een bestand onder tmp_path, draai main(["score", ...]) met --token-file dat ernaar wijst en refused_with(401), en controleer exitstatus 1, 401 op standard error, en het token op geen van beide streams. De meegeleverde main leest dat bestand met read_token, dat drie regels lang is:

def read_token(path):
    with open(path, encoding="utf-8") as file:
        return file.read().strip()

Roep elke functie aan via haar module, scoreboard_server.add_viewer(...) en scoreboard_client.main(...), nooit via een naam die met from is geïmporteerd. Hoofdstuk 7 gaf de reden, en die doet er hier nog meer toe: Check my work wisselt andere versies van je functies in via de module, en een naam die met from is geïmporteerd, zou het origineel houden.

Wat Check my work doet

Check my work draait je tests in twee rondes. Eerst zoals ze zijn, tegen je eigen code: elke test moet slagen. Daarna één keer voor elk van acht versies van je code die elk één realistische fout maken, met één functie vervangen:

1. de outbox van een nieuwe kijker begint leeg, dus die krijgt niets toegestuurd tot de volgende score;

2. de snapshot bij binnenkomst van een nieuwe kijker heeft de versie van het bord, maar elk team op 0 punten;

3. een score wordt alleen aan de eerste kijker aangeboden;

4. iedereen mag scoren, met of zonder token;

5. watch drukt een snapshot af die niet nieuwer is dan de laatste;

6. score meldt succes als de handshake wordt geweigerd;

7. een outbox bewaart de oudste snapshot in plaats van de nieuwste;

8. een kijker wordt alleen uit het register verwijderd als zijn verbinding sluit.

Tegen elk hiervan moet minstens één van je tests falen. Drie van de acht worden ook betrapt door tests die je al hebt uit hoofdstuk 8: de lege outbox (een kijker die niets krijgt, wacht, en de exittest merkt dat), de oudste snapshot en het verwijderen. De tweede wordt alleen betrapt door een test voor binnenkomen die de scores controleert, dus controleer die. Elke run wordt gestopt als er na drie seconden nog een test draait, en een gestopte run van een foutieve versie telt als opgemerkt.

Deze tests bewijzen de regels één aanroep tegelijk. Ze draaien geen thread, dus ze kunnen de race bij het binnenkomen of aan het eind van de quiz niet laten zien; dat deel wordt bewezen door de eigen controles van Check my work, die je in les 1 tot en met 3 al hebt gehaald.

Je opdracht

Vervang de drie stubs aan het eind van tests/test_scoreboard.py die les 4 noemt en de twee in tests/test_client.py door echte tests. Houd hun namen: de vierde stub in tests/test_scoreboard.py is voor les 5, en Check my work laat die op naam weg. Je mag eigen tests en hulpfuncties toevoegen.

python -m pytest -q
echo $?

Als je vijf tests geschreven zijn, meldt pytest 1 failed en 12 passed, en echo $? drukt nog steeds 1 af: degene die faalt, is de stub van les 5, test_the_last_update_is_sent_before_the_close. Les 5 schrijft hem, draait de hele quizavond en controleert alles in één keer.