Utilizzo di TDD per creare un report

Question

Attualmente sto cercando di utilizzare PHPUnit per informazioni su Test Driven Development (TDD) e ho una domanda sulla scrittura di report utilizzando TDD.

Prima di tutto: ho capito il processo di base del TDD:

Ma la mia domanda è questa: come si usa TDD di scrivere una relazione?

Supponiamo che tu sia stato incaricato di scrivere un rapporto sul numero di automobili che passano da una determinata intersezione per colore, tipo e peso. Ora, tutti i dati sopra riportati sono stati catturati in una tabella di database ma ti viene chiesto di correlarli.

Come si va a scrivere test per un metodo di cui non si conosce l'esito? L'esito del metodo che mette in correlazione questi dati cambierà in base all'intervallo di date e ad altri criteri limitanti che l'utente può fornire durante l'esecuzione del report? Come lavori nei confini del TDD in questa situazione usando un framework come PHPUnit?

Answer 1

È possibile creare preventivamente dati di test che rappresentano il tipo di dati che si riceveranno in produzione, quindi testare il proprio codice in base a ciò, aggiornando la tabella ogni volta che si esegue il test (ad esempio nella funzione SetUp()).

Non è possibile testare i dati effettivi che si riceveranno in produzione, non importa cosa si sta testando. Stai solo testando che il codice funzioni come previsto per un determinato scenario. Ad esempio, se carichi la tabella di test con cinque file di auto blu, allora il tuo rapporto mostrerà cinque auto blu quando lo testerai. Stai testando le parti del rapporto, in modo tale che quando hai finito avrai testato l'intero rapporto automaticamente.

Come confronto, se si testasse una funzione che prevede un numero intero positivo compreso tra 1 e 100, si scriveranno 100 test per verificare ogni singolo intero? No, testare qualcosa all'interno dell'intervallo, quindi qualcosa sopra e attorno ai limiti (ad esempio -1, 0, 1, 50, 99, 100 e 101). Non testare, ad esempio, 55, perché quel test scenderà lo stesso percorso di codice di 50.

Identificare i percorsi e i requisiti del codice, quindi creare test adatti per ognuno di essi. I tuoi test diventeranno un riflesso delle tue esigenze. Se i test passano, il codice sarà una rappresentazione accurata dei tuoi requisiti (e se i tuoi requisiti sono sbagliati, TDD non può comunque salvarti da questo).

Answer 2

Non si utilizzano gli stessi dati quando si eseguono le suite di test e quando si esegue lo script. Usi i dati di test. Quindi, se vuoi interagire con un database, una buona soluzione è creare uno sqlite database stored in your ram.

Analogamente, se la funzione interagisce con un file system, è possibile utilizzare a virtual filesystem.

E se si deve interagire con gli oggetti, you can mock them too.

La cosa buona è che puoi testare con tutti i dati casuali di bordo che pensi quando scrivi il codice (ehi, e se i dati contengono virgolette senza caratteri?).

Answer 3

È molto difficile, e spesso imprudente, testare direttamente contro il server di produzione, quindi la soluzione migliore è fingere.

Innanzitutto, si crea uno stub, un oggetto speciale che supporta il database che consente di fare in modo che i test dell'unità provino che alcuni valori provengono dal DB quando proveniva proprio da te.Se necessario, hai qualcosa che è in grado di generare qualcosa che non è conoscibile da te, ma comunque accessibile dai test.

Una volta che tutto funziona lì, si può avere un set di dati nel DB sé in qualche schema di test - in pratica, ci si connette ma con diversi parametri in modo che, mentre si pensa che sta guardando PRODUCTION.CAR_TABLE è davvero guardando TESTING.CAR_TABLE . Si potrebbe anche voler avere il test drop/create table ogni volta (anche se questo potrebbe essere un po 'troppo porta a test più affidabili).