Il problema è ben noto e la parola chiave che stai cercando è pooling .
L'idea è che l'apertura di una connessione è un'operazione complicata: di solito richiede il raggiungimento del server, l'autenticazione, il controllo dei diritti, il controllo, ecc.
D'altra parte, preservare la stessa connessione attraverso l'applicazione memorizzandola in una variabile statica o passandola a tutti i metodi che potrebbero richiedere l'accesso al database di solito è brutta e difficile da implementare. Senza contare il fatto che in questo caso, la connessione potrebbe rimanere aperta per un lungo periodo mentre non viene utilizzata, raggiungendo infine il numero massimo di connessioni consentite dal server.
Il pool di connessioni consiste nel preservare il pool di connessioni sotto il cofano per consentire al programmatore di aprire la connessione e chiuderla non appena non è più necessaria. Le connessioni effettive sono gestite in modo trasparente, il che significa che non si ha più il surriscaldamento di una connessione aperta e che si è meno a rischio di utilizzare tutte le connessioni disponibili.
Ulteriori letture:
Ora, non riutilizzare la connessione non significa che devi duplicare la logica del database in tutti i tuoi test. Puoi mettere la logica di connessione e smaltimento in una classe con i metodi speciale __enter__
e __exit__
, e quindi usarlo come :
with DatabaseConnection() as db:
cursor = db.connection.cursor()
...
Da notare che, menzionando i test nel tuo esempio di codice:
-
Potresti essere interessato a utilizzando un framework di test . Dopotutto, hai detto che "giocavi solo con Python, imparando facendo", quindi perché non imparare anche un framework di test di Python?
-
Come altri hanno notato, i test unitari non dovrebbero accedere a un database. Ma l'accesso ai database è perfettamente soddisfacente nei test di integrazione o di sistema.