Preparazione test di unità: Che cosa è importante da tenere a mente quando si lavora su un'architettura software? [chiuso]

Question

Diciamo che sto iniziando un nuovo progetto, la qualità è una priorità assoluta.

ho intenzione di fare test approfonditi unità, ciò che è importante da tenere a mente quando sto lavorando sull'architettura per facilitare e potenziare ulteriormente test di unità?

modifica : ho letto un articolo qualche tempo fa (non riesco a trovare ora) a parlare di come il disaccoppiamento di istanze di codice di classi comportamenti potrebbe essere essere utile quando unit testing. Questo è il tipo di suggerimenti per la progettazione sto cercano qui.

Answer 1

Facilità di test passa attraverso essere in grado di sostituire il maggior numero di dipendenze tuo metodo ha con il codice di prova (prende in giro, falsificazioni, ecc) Il modo in cui attualmente raccomandato per farlo è attraverso inversione di dipendenza, alias il Principio di Hollywood: "Don 't ci chiamano, ti chiameremo ". In altre parole, il codice dovrebbe "chiedere le cose, non guardare le cose".

Una volta che si comincia a pensare in questo modo troverete codice può facilmente avere dipendenze da molte cose. Non solo avete dipendenze da altri oggetti, ma database, file, variabili di ambiente, le API del sistema operativo, globali, single, ecc Aderendo ad una buona architettura, è ridurre al minimo la maggior parte di queste dipendenze, fornendo loro tramite gli strati appropriati. Così, quando arriva il momento di testare, non è necessario un database di lavoro pieno di dati di test, si può semplicemente sostituire l'oggetto di dati con un oggetto dati finto.

Questo significa anche che dovete risolvere con attenzione la vostra costruzione oggetto dalla tua esecuzione dell'oggetto. La "nuova" dichiarazione collocato in un costruttore genera una dipendenza che è molto difficile da sostituire con una finta di prova. E 'meglio passare quelle dipendenze in via argomenti del costruttore.

Inoltre, osservare la Legge di Demetra in mente. Non scavare più di uno strato profondo in un oggetto, altrimenti si creano dipendenze nascoste. Chiamando Flintstones.Wilma.addChild (ghiaia); significa quello che si pensava fosse una dipendenza "antenati" è in realtà una dipendenza da entrambi "Flintstones" e "Wilma".

Answer 2

Assicurarsi che il codice è testabile rendendolo altamente coesivo, umile disaccoppiato. E assicurarsi di sapere come utilizzare gli strumenti di scherno per deridere le dipendenze durante i test di unità.

Vi consiglio di acquisire familiarità con i href="http://en.wikipedia.org/wiki/Solid_(Object_Oriented_Design)" SOLIDO principio , in modo da in grado di scrivere un codice più verificabili.

Answer 3

Si potrebbe anche voler controllare questi due SO domande:

• Unit Test Adozione
• che dovrebbe essere un'Unità

Answer 4

Alcuni pensieri casuali:

• Definisci le interfacce: disaccoppiare i moduli funzionali gli uni dagli altri, e decidere in che modo comunicare tra loro. L'interfaccia è il “contratto” tra gli sviluppatori di diversi moduli. Poi, se i test operano sulle interfacce, si sta assicurando che le squadre possono trattare di ogni altri moduli come scatole nere, e quindi lavorare in modo indipendente.

• costruire e testare almeno le funzionalità di base dell'interfaccia utente prima. Una volta che il progetto può “parlare” a te, può dire cosa funziona e cosa non lo è ... ma solo se non sta mentendo a voi. (Bonus:. Se gli sviluppatori hanno altra scelta che utilizzare l'interfaccia utente, ti identificare rapidamente eventuali carenze in termini di facilità d'uso, il flusso di lavoro, etc )

• Prova a livello pratico più basso:. il più sicuri siete che i piccoli pezzi da lavorare, tanto più facile sarà per combinarli in un insieme di lavoro

• Scrivi almeno una prova per ogni funzione, sulla base delle specifiche, prima di iniziare a scrivere codice. Dopo tutto, le caratteristiche sono la ragione per i vostri clienti acquistare il prodotto. Essere sicuro che sia progettato per fare quello che si suppone di fare!

• Non essere soddisfatti quando si fa quello che si suppone di fare; assicurarsi che non fare quello che è non supposto per fare! Gli alimenti dati non validi, utilizzarlo in maniera illogica, scollegare il cavo di rete durante il trasferimento dei dati , eseguirlo al fianco di applicazioni in conflitto. I vostri clienti.

In bocca al lupo!

Answer 5

I tuoi test saranno sempre e solo essere buono come le vostre esigenze. Possono essere i requisiti che si arriva con davanti tutti in una volta, possono essere requisiti che si arriva con uno alla volta quando si aggiungono le caratteristiche, oppure possono essere requisiti che si arriva con dopo lo spedite e la gente inizia a segnalazione di un battello carico di bug, ma non si può scrivere un buon test se nessuno può o vuole documentare esattamente ciò che si suppone la cosa da fare.