Situazione attuale
Ho una situazione che trovo frustrante: i test di integrazione nel mio progetto (un'API RESTful) contengono sia le chiamate HTTP API che le query SQL. Ogni volta che viene effettuata una chiamata API che scrive qualcosa sul DB (una richiesta POST, PUT o PATCH), viene avviata una query SQL scritta a mano per confrontare la risposta dell'API con il DB. Quindi:
- Invia richiesta POST, ricevi risposta
- Invia query SQL, ricevi risposta
- Confronta le due risposte
I test di integrazione si svolgono in un progetto separato, quindi è impossibile utilizzare solo l'ORM del progetto principale e non analizzare le risposte del DB negli oggetti di business che stiamo utilizzando.
Problema
Ho un problema con la dura dipendenza tra la struttura del DB e i test di integrazione.
Il progetto è giovane e la struttura del database è in costante cambiamento. Ogni volta che si verifica una modifica nel DB, le query SQL in tutti i test di integrazione interessati vanno fuori sincrono e devono essere aggiornate manualmente. Quando il cambiamento è piccolo, di solito non è un grosso problema, ma ogni volta ad es. una colonna viene modificata in una chiave esterna, tutte le query interessate iniziano improvvisamente a richiedere un join, le colonne selezionate necessitano di alias di tabella per evitare nomi di colonne ambigue.
Questo diventa un problema soprattutto quando i test stessi creano le query SQL da blocchi elementari più piccoli: una clausola WHERE può essere passata come argomento a un metodo che restituisce l'SQL o forse una seconda query potrebbe essere costruita sulla base di alcuni parametri utilizzati nel primo.
Infine, ogni volta che una raccolta è contenuta nella risposta dell'API, di solito si tratta di un join nell'SQL che richiede un'ulteriore elaborazione (modifica n di righe selezionate in una singola riga con una raccolta in una delle colonne).
In cima a questo, dato che i test di integrazione richiedono alcune ore per essere completati, non esiste un riscontro immediato che ci sia un problema, che prolunga il tempo necessario per risolvere eventuali problemi.
In breve, una piccola modifica nella struttura del DB spesso si traduce in diversi giorni lavorativi sprecati per l'aggiornamento di SQL e della logica di compilazione SQL nei test di integrazione .
Motivazioni
Il razionale per avere query SQL nei test di integrazione sembra essere che il team abbia riscontrato problemi con la struttura del DB: i dati recuperati erano corretti, ma erano stati salvati in modo errato nel database.
Questa è la spiegazione data a me quando ho sollevato il problema. Non lo compro
Soluzione
Quindi qual è l'approccio migliore?
Credo che se testiamo l'API, dovremmo fare affidamento sulle chiamate API esclusivamente per confrontare le risposte ed eliminare del tutto l'SQL, quindi:
- Invia richiesta POST, ricevi risposta
- Invia richiesta GET per l'entità interessata, ricevi risposta
- Confronta i due
Tuttavia, se il team afferma che la struttura del database deve essere verificata, non so quale soluzione offra loro invece di ciò che abbiamo attualmente.
Gradirei qualsiasi suggerimento, suggerimento o link a articoli (preferibilmente brevi) che affrontino questo problema.