Einen Commit durch erneutes Öffnen belegen

Eine erfolgreiche Ausleihe kann auf ihrer schreibenden Verbindung korrekt aussehen, obwohl sie nie festgeschrieben wurde. Diesen Schreiber zu schließen und über eine neue Verbindung zu lesen macht die dauerhafte Speicherung beobachtbar.

Bearbeite tests/test_catalog.py und vervollständige test_checkout_commit_survives_reopening(tmp_path). Erstelle durable-checkout.db unterhalb von tmp_path, öffne sie über catalog_db.open_database und füge einen unbekannten Gegenstand sowie ein Mitglied mit freiem Ausleihplatz ein. Schreibe nur diese Vorbereitung fest. Rufe dann catalog_db.checkout_item(connection, 701, 501, 601, "2034-06-12") auf und sichere zu, dass es die ausdrücklich angegebene Ausleih-ID 701 zurückgibt.

Rufe nach checkout_item kein connection.commit() auf. Die Funktion ist für diese erfolgreiche Transaktion verantwortlich. Schließe den Schreiber in finally, öffne denselben Pfad mit sqlite3.connect und lies id, item_id, member_id, checked_out_on und returned_on für Ausleihvorgang 701. Vergleiche das exakte gespeicherte Tupel, einschließlich None als noch fehlender Rückgabeangabe des aktiven Ausleihvorgangs, und schließe dann den Leser.

Halte die beiden Verbindungslebenszyklen im Test sichtbar getrennt. Diese Struktur macht die Aussage über dauerhafte Speicherung leicht lesbar und verhindert, dass eine spätere Änderung versehentlich den Schreiber wiederverwendet.

Das ist ein Test des Transaktionsverhaltens. Die Aktion ist der öffentliche Ausleihaufruf. Die entscheidende Zusicherung stammt aus einem späteren Verbindungslebenszyklus. Ein Test, der über den Schreiber liest, kann bestehen, während seine Einfügung noch offen ist. Ein Test, der für das Programm festschreibt, repariert unbemerkt genau den Fehler, den er aufdecken soll. Nur die zurückgegebene 701 zu prüfen belegt den Python-Rückgabewert, nicht das Datenbankergebnis.

Klicke auf Run. run_tests.py ruft erneut genau pytest.main(["-q", "-p", "no:cacheprovider", "tests/test_catalog.py"]) auf. Fünf unabhängige Tests sollten Folgendes erzeugen:

Database tests passed: 5

Submit führt die korrekte Testsuite zweimal aus und prüft sie dann gegen eine Ausleihimplementierung, die die Einfügung ohne ihren Transaktionskontext ausführt. Das Schließen deines Schreibers rollt diese offene Zeile zurück, also sollte die erneut geöffnete Abfrage keinen Ausleihvorgang finden und der Test an der Beobachtung der dauerhaften Speicherung scheitern. Dieser Fehler sagt genau, was zu untersuchen ist: Wer verantwortet den Commit, und fand das Lesen auf einer tatsächlich neuen Verbindung statt?