Che cos’è un test di accettazione?
Jacopo chiede:
cos’è un test di accettazione? e uno di integrazione? usiamo i sistemi veri o quelli finti?
La mia risposta: Un test di accettazione ha lo scopo di dimostrare che abbiamo capito tutto quello che c’è da fare per una storia d’uso. Il test d’accettazione serve per
- dimostrare al cliente che abbiamo capito quello che chiede
- chiedere conferma al cliente se abbiamo capito quello che chiede
- nel processo di fare le ultime due cose, avviare un dialogo costruttivo sul cliente basato su *esempi* di come deve comportarsi il sistema.
Per fare questo, non è necessario passare per l’interfaccia utente e nemmeno usare i sistemi veri; ci si può semplicemente collegare direttamente alle classi di dominio che fanno il ragionamento.
One of the most common mistakes in creating customer tests is describing what happens in the user interface rather than providing examples of business rules. … Good examples focus on the essence of your rules. Rather than imagining how these rules might work in an application, think about what your rules are. If you weren’t creating an application, how would you describe those rules to a collegue? Talk about things rather than actions. … It takes a bit of practice to learn to think this way, but the results are worth it. The tests become more compact, easier to maintain, and … faster to run.
Shore and Warden, The Art of Agile Development, p. 285.
Quindi un test di accettazione NON E’ UNA DEMO!
La demo deve essere il più possibile interattiva. Per fare una demo è utile avere una interfaccia utente con cui giocare. Se il progetto è batch, conviene creare una mini-interfaccia molto semplice, magari basata su riga di comando, per stimolare il sistema. Perché i nostri test di accettazione stimolano il sistema su un insieme di esempi fissato. Invece durante la demo, e durante il test esplorativo, è importante essere in grado di provare cose diverse che ti vengono in mente e vedere rapidamente come reagisce il sistema.
Philosophically, exploratory testing is similar to test-driven development and incremental design: rather than designing a huge suite of tests up-front, you design a single test in your head, execute it against the software, and see what happens. Ther result of each test leads you to design the next.
Shore and Warden, The Art of Agile Development, p. 345.
Un test di integrazione, invece è un test che prova che il nostro sistema interagisce correttamente con *un* sottosistema esterno. Se sviluppi secondo l’architettura esagonale, il test di accettazione verifica l’implementazione corretta di *un* lato dell’esagono.
Un test di integrazione end-to-end, invece, testa il sistema tutto, con i suoi collaboratori esterni, dall’interfaccia utente. In molti casi il test end-to-end non conviene; perché è lento, fragile e difficile da manutenere. I test di integrazione focalizzati, insieme ai test unitari e ai test di integrazione, sono di solito sufficienti a darmi una buona confidenza sulla qualità del mio sistema. Ma soprattutto, il test di integrazione end-to-end non è efficace come il test esplorativo. Magari il test end-to-end è verde, ma appena provo a usare il sistema in maniera interattiva va tutto a pezzi.
Instead of end-to-end tests, use exploratory testing to check the effectiveness of your unit and integration tests. When your exploratory tests find a problem, use that information to improve your approach to unit and integration testing, rather than introduce end-to-end tests.
Shore and Warden, The Art of Agile Development, p. 305.
November 22nd, 2008 at 19:03
iniziando a fare unit testing interation-based anchei test state-base che scrivevo hanno iniziato a diventare più unitari
cosi ho sentito il bisogno di scrivere di integrazione per testare come gli oggetti funzionano insieme – anche quando non c’è un sotto-sistema esterno
x fare un esempio – quando scrivo una feature nuova gli scrivo tutti e tre (stare-based, interation-based e integration) e mi sono utili tutti e tre da subito per fare refactoring con tranquillità e anche osare di più
November 23rd, 2008 at 09:05
Ciao Luca,
quello che intendiamo noi per “integration test” è un test che non soddisfa i requisiti di Michael Feathers (http://www.artima.com/weblogs/viewpost.jsp?thread=126923), cioè di solito un test che parla con un sistema esterno, di solito il DB. Un test che stimola l’interazione di più oggetti, purché siano tutti oggetti definiti da noi che eseguono all’interno del nostro processo, lo chiamiamo comunque un unit test.
November 23rd, 2008 at 14:28
[…] Matteo started discussing, posting his ideas on acceptance and integration tests. he has done a great work, trying to explain his point of view while showing other’s, such as […]