Dipendenze in test di accettazione

Question

Io e un collega stanno avendo un dibattito. Siamo su un progetto legacy craptastic e stiamo aggiungendo lentamente prove di collaudo. Egli ritiene che dovremmo fare il lavoro nella gui / Watin quindi utilizzando una libreria di basso livello per interrogare il database direttamente per ottenere un 'end to end' test come dice lui.

Stiamo usando NHibernate e che sostengo con gui / Watin poi quegli oggetti NHibernate di fare le affermazioni del test di accettazione. Egli non ama la dipendenza di NHibernate nel test. La mia affermazione è che abbiamo / dovrebbe avere test di integrazione nei confronti del NHibernate oggetti per assicurarsi che stanno lavorando con DB il modo in cui intendiamo il punto in cui non v'è alcun aspetto negativo nel loro utilizzo nel test di accettazione per affermare il corretto funzionamento. Penso anche che la sua dipendenza SQL basso livello farà le prove di logica di business fragile e duplicato in un sacco di casi.

testing di integrazione nel nostro negozio in pratica significa la sua un singolo componente, con una dipendenza per esempio FileRepository / FileSystem Domain-NhibernateObject / Database. mezzi di prova di accettazione provenienti attraverso la GUI. mezzi ad unità tutte le dipendenze sono / possono essere derisi / spense e hai un test puro in memoria con solo il metodo in prova in realtà fare alcun vero lavoro. Fatemi sapere se i miei defs sono spenti.

In ogni caso qualsiasi articoli / docs / pergamena con pareri su questo tema che mi può puntare al sarebbe apprezzato.

Answer 1

L'unica ragione che ci si mai automatizzare i test è quello di rendere le cose più facili da cambiare. Se non li stava cambiando, si potrebbe ottenere via con test manuale. Legare i test al database renderà il database molto più difficile da cambiare.

legandoli alla NHibernate oggetti non aiuterà molto più di tanto, ho paura!

Gli utenti del sistema non sarà utilizzando il database o NHibernate. Come fanno a ottenere il beneficio (o fornire il beneficio per le altre parti interessate)? Come potranno essere in grado di dire che sta lavorando bene? Se si riesce a catturare che in prove di collaudo, sarete in grado di cambiare il codice sottostante e dei dati, pur mantenendo il valore della vostra applicazione. Se qualcuno genera report dai dati, perché non generare gli stessi report e controllare che il loro contenuto è quello che vi aspettate? Se i dati vengono letti da un altro sistema, si può ottenere una copia di tale sistema e vedere che cosa uscite di la sua utenti?

In ogni caso, questa è la mia opinione - prove di mantenere accettazione come vicino al valore di business possibile - e qui è un post che ho scritto che potrebbe aiutare. Si potrebbe anche provare il Behavior Driven Development gruppo su Yahoo, che hanno un bel po 'di esperienza tra di loro.

Oh, e facendo test di integrazione per controllare che le associazioni (N) Hibernate sono buone è un'ottima idea. Ci ha salvato su un paio di progetti.