Bewijs een commit door opnieuw te openen

Een geslaagde uitleen kan correct lijken op de verbinding die schrijft, ook wanneer die nooit is gecommit. Door die schrijvende verbinding te sluiten en via een nieuwe verbinding te lezen, maak je blijvende opslag waarneembaar.

Bewerk tests/test_catalog.py en maak test_checkout_commit_survives_reopening(tmp_path) af. Maak durable-checkout.db onder tmp_path, open die via catalog_db.open_database en voeg één nog niet gebruikt voorwerp toe plus een lid dat ruimte heeft om te lenen. Commit alleen deze beginsituatie. Roep daarna catalog_db.checkout_item(connection, 701, 501, 601, "2034-06-12") aan en controleer met een assertion dat de functie het expliciete uitleen-ID 701 teruggeeft.

Roep na checkout_item geen connection.commit() aan. De functie is verantwoordelijk voor die geslaagde transactie. Sluit de schrijvende verbinding in finally, open hetzelfde pad met sqlite3.connect en lees id, item_id, member_id, checked_out_on en returned_on voor uitlening 701. Vergelijk de exacte opgeslagen tuple, inclusief None voor de terugbrengwaarde van de actieve uitlening, en sluit daarna de lezende verbinding.

Houd de twee levenscycli van de verbindingen visueel gescheiden in de test. Die structuur maakt de claim over blijvende opslag goed leesbaar en voorkomt dat een latere wijziging ongemerkt de schrijvende verbinding hergebruikt.

Dit is een test van transactiegedrag. De actie is de publieke uitleenaanroep. De doorslaggevende assertion gebruikt een verbinding uit een latere levenscyclus. Een test die via de schrijvende verbinding leest, kan slagen terwijl de insert nog niet is vastgelegd. Een test die voor het programma commit, herstelt ongemerkt precies het defect dat die moet aantonen. Alleen de teruggegeven 701 controleren bewijst de Python-terugkeerwaarde, niet de database-uitkomst.

Druk op Run. run_tests.py roept opnieuw precies pytest.main(["-q", "-p", "no:cacheprovider", "tests/test_catalog.py"]) aan. Vijf onafhankelijke tests moeten dit opleveren:

Database tests passed: 5

Submit voert de correcte suite twee keer uit en controleert die daarna met een uitleenimplementatie die de insert zonder transactiecontext uitvoert. Het sluiten van je schrijvende verbinding draait die nog niet vastgelegde rij terug. De query na heropenen moet dus geen uitlening vinden en de test moet mislukken bij de controle op blijvende opslag. Die fout wijst precies aan wat je moet inspecteren: wie verantwoordelijk is voor de commit en of het lezen via een echt nieuwe verbinding gebeurde.