Come gestire tali scenari?

Question

Quando un software è sviluppato, i vari tipi di test è fatto - unità, l'integrazione, funzionale, manual.In mio progetto in corso (WinForms con sql server), che ha il codice legacy (nessun test), abbiamo molti bug . Stiamo cercando di rimuoverli utilizzando combinazione di test manuali + (per lo più l'integrazione)

Ma, ancora alcuni bug può sfuggire.

Per esempio (un ipotetico scenario) -. Se un cliente ha acquistato un po 'di dollari di merci per ultimi 6 mesi, dovrebbe essere dato un po' di sconto su acquisti si fa una volta 6 mesi hanno lo status di lapsed.His dovrebbe essere aggiornato a privilegiare

Ma, per qualche ragione (bug nel codice) il sistema non sta facendo so.How dovremmo affrontare tali scenari? Dovremmo avere uno script in esecuzione sul database che cerca scenari come descritto? Un'altra estensione dello scenario potrebbe essere, il cliente deve essere inviare un dono, una volta che è privilegiata, ma il sistema non è presente a farlo.

Pensieri?

Answer 1

"Dovremmo avere uno script in esecuzione sul database che cerca scenari come descritto?"

Vuoi dire "mettere uno script nel database per risolvere il problema", quindi su non .

NO. Mai. In nessuna circostanza. Lavorando attorno a un bug con l'aggiunta di logica speciale-caso particolare è davvero una pessima idea.

1. Quando quella logica speciale-caso particolare ha il proprio bug, hai aggiunto il codice buggy per cercare di codice buggy corretto. Una perdita netta.

2. Quando si tenta di migliorare il sistema, si ha questa logica peculiare special-case, che non ha alcun senso.

   a. Se siete fortunati, si fissa il bug che avrebbe dovuto risolvere, e sarà ridondante. E adesso? Quale copia per rimuovere?

   b. In caso contrario, sarà in contraddizione con altro codice. E adesso? Quale è giusto?

Se vuoi dire "metti uno script nel database per aiutare a trovare ed eseguire il debug del problema", allora sì. Per un breve periodo, utilizzare tutti gli strumenti a vostra disposizione per trovare e correggere gli errori. Una volta trovato e risolto, questo script è quindi inutile e deve essere eliminato.

Se vuoi dire "scrive uno script nel database per testare l'applicazione", allora sì. Questo è ciò che gli script di test unità sono per. Usali.

E 'molto meglio per creare test di unità che è di creare script che si mette nel database. I test unitari sono l'approccio migliore.

Answer 2

Si dovrebbe avere un test-suite automatizzata in atto. Questo test-suite implementerà tutti gli scenari che la specifica richiede. Dal momento che non si può aspettare sei mesi per verificare che i lavori di attualizzazione, l'effettiva attuazione è sostituito da un implementazione finta (l'esempio è in java, ma gli stessi principi si applicano in altre lingue), che, per esempio 'simula' che 6 mesi sono passati. Si può usare affermazioni per automatizzare i test.

Una volta che avete l'intero test-suite di pronto, se tutti i test passano dopo (come prima) un refactoring / modifica del codice, si può essere certi che nessuna caratteristica si è rotto a causa del refactoring.