Abbiamo bisogno di dati di test o possiamo fare affidamento su test unitari e test manuali?

Stai mescolando due concetti diversi. Uno è verifica , che si basa su Test unitario e Recensioni peer. Questo può essere fatto dagli sviluppatori stessi, senza dati di test e il suo scopo è quello di verificare che una serie di requisiti siano soddisfatti.

Il secondo è validation , e questo è fatto dal QA (i tuoi tester). Per questo passaggio è necessario disporre di dati di test poiché il tester non deve avere alcuna conoscenza della programmazione nell'applicazione, ma solo i casi d'uso previsti. Il suo obiettivo è quello di verificare che l'applicazione si comporti come previsto in un ambiente di produzione.

Entrambi i processi sono importanti e necessari per fornire un prodotto di qualità al cliente. Non puoi fare affidamento solo sui test unitari. Quello che devi capire è un modo affidabile per gestire i tuoi dati di test per garantirne la validità.

EDIT: OK, ricevo quello che stai chiedendo. La risposta è sì, perché il compito del tester non è quello di generare i dati di test, solo per testare l'applicazione. È necessario creare gli script in modo da consentire una manutenzione più semplice e l'inserimento di dati validi. Senza i dati del test, il tester non avrà nulla da testare. Detto questo, tuttavia, se hai accesso all'ambiente di test , non vedo perché non puoi inserire manualmente i dati del test piuttosto che utilizzare gli script.

Sì, avere test unitari e modelli di dati è una buona pratica. Il project manager è corretto. Dal momento che eseguire una modifica "semplice" nei dati di test spesso produce errori, allora questo è il nocciolo del problema.

Il codice ha bisogno di miglioramenti. Non farlo (dicendo hey non abbiamo bisogno di test) non è una soluzione, si tratta semplicemente di aggiungere debito tecnico . Rompa il codice in unità più piccole e testabili perché non è possibile identificare le unità senza rotture è un problema.

Iniziare a fare un refactoring. Mantieni i miglioramenti piccoli in modo che siano gestibili. Cerca anti-modelli come le classi / metodi di Dio, non seguendo DRY, la singola responsabilità, ecc ...

Infine, guarda TDD per vedere se funziona per la squadra. TDD funziona bene per garantire che tutto il tuo codice sia in grado di testare (perché scrivi prima i test) e inoltre assicurati di rimanere lean scrivendo solo il codice sufficiente per superare i test (minimizzare l'ingegneria).

In generale, se una serie di complessi processi di business logic producono un insieme di dati, allora lo vedo come un rapporto. Incapsulare il report. Esegui il rapporto e utilizza l'oggetto risultante come input per il test successivo.

Questo è un problema molto comune e molto difficile. I test automatici eseguiti su un database (anche un database in memoria, come HSQLDB ) sono in genere lenti, non deterministici e, dal momento che un test l'errore indica solo che c'è un problema da qualche parte nel tuo codice o nei tuoi dati, non sono molto istruttivi.

Secondo la mia esperienza, la strategia migliore è concentrarsi sui test unitari per la logica aziendale. Cerca di coprire il più possibile il tuo codice di dominio principale. Se si ottiene questa parte correttamente, che è di per sé una vera sfida, si otterrà il miglior rapporto costi-benefici per i test automatizzati. Per quanto riguarda il livello di persistenza, di solito investo molto meno sui test automatici e lo lascio ai tester manuali dedicati.

Ma se vuoi veramente (o hai bisogno) di automatizzare i test di persistenza, ti consiglio di leggere Oggetto in crescita -Oriented Software, Guided by Tests . Questo libro ha un intero capitolo dedicato ai test di persistenza.