Unit Testing
Download as PPTX, PDF•0 likes•31 views
Il documento discute il passaggio dai test manuali al continuous testing, evidenziando l'importanza degli unit test e del Test Driven Development (TDD) nel migliorare la qualità del software e ridurre i costi. Viene sottolineato come il TDD permetta di scrivere codice migliore attraverso un approccio incrementale e l'integrazione continua, mentre vengono analizzati i vantaggi e gli svantaggi di test automatizzati rispetto a quelli manuali. Inoltre, si affrontano strategie come i mock e gli stub per facilitare i test di integrazione.
![22
AAA pattern
• Arrange
Creazione dell’ambiente applicativo che
si vuole testare.
• Act
Esecuzione del codice che si vuole
testare
• Assert
Verifica e validazione dei risultati
ottenuti
[TestMethod]
public void NoNewMessages()
{
//Arrange
Mailbox mailbox = new Mailbox();
//Act
var result = mailbox.GetCount(0);
//Assert
Assert.AreEqual("No new messages.", result);
}](https://image.slidesharecdn.com/presentazioneunittest-181111074445/85/Unit-Testing-21-320.jpg)
Unit Testing
- 1. Unit test Dai test manuali al continuous testing ARGOMENTO
- 2. 2 Agenda 1 Introduzione 1. Pattern test 2 TDD 1. Dall’approccio tradizionale al testing 3 Unit e Integration Test 1. Mock, stubs, fake 2. Esempi prativi 4 Continuous testing
- 4. 4 Svantaggi • Richiede molto tempo di sviluppo (tempo = costo!) • Richiede enorme pazienza al team di sviluppo • Necessita di una rigorosa documentazione • Non è possibile testare tutti gli input e gli scenari come nel mondo reale
- 8. 8 Costo dei test Rampa creata in tempo e nel budget!
- 9. 9 Ciclo di vita del codice • Unit test è un segmento di codice utilizzato per testare un pezzo di codice applicativo • Verifica se il codice: o Rispetta i requisiti e il design o Si comporta come previsto o Aiuta a identificare gli algoritmi e lo logiche errate
- 10. 10 I componenti fondamenti di un test • Il test deve essere leggibile • Il test deve essere veritiero • Il test deve essere mantenibile • Il test deve essere ISOLATO • Il test deve essere veloce • Il test si deve documentare da se (nomenclatura) • Il test non deve contenere logica
- 11. 11 Manual vs Automated • Test automatizzati Decrementano drammaticamente il numero di difetti del codice Migliorano il disegno app. Sono una buona documentazione Riducono il costo ai cambiamenti Consento refactoring • Test manuali Richiede una persona designata ai test ad ogni release Meno efficiente Non strutturato Non ripetibile Non comprensibile rispetto al codice
- 12. 12 Tipi di test End to end (black-box) Difficili da scrivere e da eseguire. Riscontrano malfunzionamenti grafici Functional test Semplici da scrivere Trovano bug di media importanza Unit test Semplici da scrivere Trovano bug di logica
- 13. 14 Tipi di test
- 14. TDD ARGOMENTO
- 15. 16 Approcci Approccio Tradizionale Test Drive Development
- 16. 17 TDD • Stile di sviluppo/ progettazione • Non è una tecnica di testing. • La programmazione e lo unit test non sono attività separate. Si scrive prima un test che fallisce, e poi si scrive il relativo codice. Differisce dagli approcci tradizionali, in cui prima si scrive il codice e poi (forse) lo si testa.
- 17. 18 Vantaggi del TDD • Permette di scrivere software migliore e più rapidamente (costruendo software in piccoli incrementi- 1 test alla volta) • Evita il procedere per tentativi • Produce codice pulito e che funziona (in modo opposto allo sviluppo architecture driven, in cui si fanno prima tutte le decisioni). • Consente agli sviluppatori di produrre un insieme di test di regressione automatizzabili, man mano che sviluppano. • Riduce il tempo per la correzione dei difetti
- 18. 19 Costo dei test La fatica ripaga
- 19. 20 Acceptance test Si trasformano i requisiti applicativi in test eseguibili.
- 20. 21 Red/Green/Refactor pattern Red Scrivi un Test che fallisce. Green Scrivi il codice per soddisfare il test. Refactor Migliora il codice senza cambiarne la funzionalità. Ripeti.
- 21. 22 AAA pattern • Arrange Creazione dell’ambiente applicativo che si vuole testare. • Act Esecuzione del codice che si vuole testare • Assert Verifica e validazione dei risultati ottenuti [TestMethod] public void NoNewMessages() { //Arrange Mailbox mailbox = new Mailbox(); //Act var result = mailbox.GetCount(0); //Assert Assert.AreEqual("No new messages.", result); }
- 22. 23 Refactoring Eliminare codice duplicato Migliorarne l’espressività Riduzione accoppiamento e migliora il codice Dopo il Refactoring, i test vanno rieseguiti.
- 24. 25 Unit test Non è Unit Test se: • comunica con il database • comunica in rete o servizi terze parti • non può essere lanciato in parallelo ad altri test • utilizza il filesystem
- 25. 26 Unit test Unit Test se: • non comunica con il database • non comunica in rete o servizi terze parti • può essere lanciato in parallelo ad altri test • non utilizza il filesystem • dovrebbe durare massimo 1 secondo
- 26. 27 Unit test Inoltre… • Scritto ed eseguito dai sviluppatori • Obiettivo: separare ciascuna parte e testare singolarmente • Eseguito prima delle integrazioni • Considera di utilizzare dei White-Box • IntelliTest https://www.microsoft.com/en-us/research/project/pex-and-moles-isolation-and-white-box-unit-testing-for-net/ • Utilizza le asserzioni per verificare le esecuzioni del codice
- 27. 28 Unit test Non solo Unit Test!
- 28. Click to edit Master title style Demo Unit - Test
- 29. Click to edit Master title style Demo Code Coverage
- 32. 33 Unit test In casa Microsoft - Martin Woodward
- 33. Mock - Stubs ARGOMENTO Un aiuto agli integration test
- 34. 35 Nomenclatura Stubs (variante test doubles) Fornisce un comportamento fissato (metodi che tornano sempre lo stesso valore). Viene usato per controllare l'"input indiretto" del codice sotto test.
- 35. 36 Nomenclatura Mock (variante spy) Memorizza esplicitamente le aspettative sul comportamento del codice sotto test, e verificare lo stato. Comportamento programmabile, che simula quello dell'oggetto reale
- 36. 37 Mock vs Stub In genere lo stub è molto più semplice di un Mock-Object. Gli stub forniscono risposte preconfezionate, e nulla che sia al di fuori di ciò che è previsto per il test. I mock hanno implementazioni più sofisticate che consentono di verificare il comportamento dell’unità testata (e non solo lo stato) verificando ad esempio le collaborazioni avute con altri oggetti ed il relativo ordine di esecuzione. Possono verificare se l’oggetto che li usa lo fa correttamente. Testano unità senza legarsi ad oggetti esterni.
- 37. 38 La classe Client (da testare) usa i metodi di Helper. Vogliamo controllare direttamente ciò che Helper restituisce a Client
- 38. Click to edit Master title style Demo Moq
- 41. Click to edit Master title style Demo
- 42. 43 Continuous testing È una pratica di sviluppo software in cui i membri del team di sviluppo integrano il proprio lavoro frequentemente, almeno una volta al giorno. Ogni integrazione è verificata da strumenti automatici che eseguono il build e riesegueno tutti i test sulla nuova configurazione, per trovare errori di integrazione rapidamente.
- 43. Click to edit Master title style Demo VSTS – continuous testing
- 44. 45 Costo dei test La fatica ripaga!
- 45. 46 Altri temi sul testing • UI testing • Selenium • Test client-side • Jasmine • Protractor (end-to-end) • SQL testing https://www.red-gate.com/blog/database-development/dont-unit-test-sql-server-code/amp