Come impostare i dati per i test di servizio

In breve, a parità di tutte le altre condizioni, l'inserimento dei dati nel database è l'approccio migliore . Riduce l'accoppiamento stretto tra le caratteristiche di business logic separate. Anche

Ho lottato con la stessa domanda non molto tempo fa. Come riferimento, ho infine convinto il PM a consentirmi di implementare una quantità base di test unitari per un progetto che è stato sviluppato senza pensare alla testabilità.

I dati nel nostro progetto sono modellati da una serie di operazioni: il progetto è un'applicazione che esegue queste numerose operazioni. Tuttavia, ci sono così tanti dati (meta) generati dopo i primi passi di X, che è diventato quasi impossibile per me generare lo stato effettivo dei dati che dovevo testare (e in alcuni casi c'erano oltre 100 combinazioni di set di dati da testare ).
Ciò è stato ulteriormente aggravato dal fatto che la struttura dei dati stava cambiando continuamente a causa di un'analisi cattiva e vaga e di un proprietario del progetto altrettanto vago.

Ci sono molti difetti nell'attuale gestione del progetto. L'analisi non dovrebbe essere stata vaga. Il codice doveva essere sviluppato tenendo presente la testabilità. L'intera struttura dei dati avrebbe dovuto essere rivista anziché copiata / incollata dall'ultimo progetto simile.

Ciononostante, questo è il progetto per cui stavo scrivendo unit test, quindi ho dovuto affrontare i fatti. Ci sono stati ulteriori motivi (non direttamente correlati al mio sviluppo) che hanno reso l'approccio corretto (data injection) quasi impossibile da ottenere.

A questo punto, ho deciso quindi di fare affidamento sulla logica di business per organizzare lo stato del database .
Ne sono felice? No. Sembra così molto sporco. Tuttavia, devo ammettere che funziona effettivamente data la situazione tutt'altro che perfetta in cui si trova già il progetto.

Il più grande svantaggio è che un piccolo errore in una delle prime operazioni causerà il fallimento di molti test, poiché quasi tutte le successive operazioni logiche dipendono dal fatto che la prima operazione sia corretta.
Ma a causa della natura lineare delle operazioni, è ancora relativamente facile individuare quale test è la causa. Alla fine abbiamo numerato i nostri test in modo che l'ordine delle operazioni (e quindi l'ordine dei test che dipendono l'uno dall'altro) sia diventato ovvio.

Per impostazione predefinita, non è consigliabile scegliere di basarsi sulla logica aziendale per impostare lo stato dei dati . Tuttavia, ci sono alcune situazioni in cui i dati sono così complicati e non sei in grado di cambiarli davvero. In quelle situazioni, può essere utile avere semplicemente la logica di generare lo stato dei dati per te semplicemente per assicurarti di poter avere alcuni test invece di nessuno affatto .

Dipende tutto dal tipo di test che intendi eseguire.

• Per i test unitari del livello accesso dati / origine dati, i dati iniettati direttamente nel database rappresentano l'approccio migliore. Con un controllo preciso sui dati di test, si riduce la potenziale causa di errori all'oggetto testato stesso. Inoltre, è possibile verificare che la propria origine dati si comporti come previsto con dati incompleti o incoerenti.

• Per qualsiasi altro test, ovvero test unitari della logica aziendale o test di integrazione:

  • db injection potrebbe comunque essere un approccio valido, ma se e solo se il modello di dati è semplice.
  • al contrario, db injection potrebbe essere controproducente con un modello di dati complesso, perché si introduce il rischio di incoerenze impreviste nei dati del test che potrebbero essere interpretate erroneamente come errore nel componente testato.

Pertanto, per i modelli di dati complessi (esclusi i test di origine dei dati), l'approccio migliore sarebbe creare dati di test utilizzando l'API. Funziona molto bene se si utilizzano le seguenti misure di mitigazione:

• assicurati che l'API per la creazione dei dati sia progettata in modo da facilitare l'automazione del test (ad esempio, l'architettura cipolla vede i componenti di test come parte integrante dell'architettura)
• assicurati che i test unitari dell'API di scrittura siano prima testati unitamente, in modo che gli errori di scrittura possano essere isolati e non inquinino i test dipendenti
• se i dati sono molto lunghi da produrre, si potrebbe immaginare un approccio misto: creare i dati di test pesanti una volta. Creare un'istantanea del database. Riavvia test dall'istantanea (ad esempio, è come se si inserissero dati, ma senza il rischio di incoerenze accidentali). continuare i test rimanenti utilizzando l'API, se necessario.

Questo ti offre il meglio di entrambi i mondi (anche se dovessi sviluppare un sistema ERP con migliaia di tabelle correlate e tipi di dati binari complicati).