Introduzione al testing

Click here to load reader

  • date post

    15-Feb-2016
  • Category

    Documents

  • view

    44
  • download

    0

Embed Size (px)

description

Dot Net Marche 6° Workshop – 27 giugno 2008. Introduzione al testing. Agenda. Unit testing , introduzione Fixture Struttura di un test xUnit Test Doubling Test Di database. Verificare la qualità generale del software Trovare bug nelle applicazioni Verificare le specifiche - PowerPoint PPT Presentation

Transcript of Introduzione al testing

Introduzione al testingDot Net Marche6 Workshop 27 giugno 20081AgendaUnit testing, introduzioneFixtureStruttura di un test xUnitTest DoublingTest Di database

2Software TestingVerificare la qualit generale del softwareTrovare bug nelle applicazioniVerificare le specificheVerificare lintegrazione tra sistemiTest di regressione

3Tipologie di testUnit TestingAutomatizzabile Scritto nello stesso linguaggio del codiceSupportato da framework standardSupporto fondamentale per refactoring e cicli di vita agiliTecnologie standard, pattern e linguaggio comune (www.xunitpattern.org)Framework xUnitTest in 4 fasi [Four Phase Test]Setup (viene impostata la situazione iniziale)Exercise (si interagisce con il SUT)Verify (si verificano gli output con asserzioni)Teardown (ripristino condizioni iniziali)Test automatizzati tramite tool a riga di comando e con interfacciaIntegrazione con il sistema di sviluppoAnatomia di un test nUnit

Classe contenente test

Shared fixture setup

Shared fixture cleanup

Fresh fixture setup

Fresh fixture cleanupTestFixtureSetUpTestSetUpTest1TearDownTestSetUpTest2TearDownTestFixtureTearDown

Le qualt di un buon testAutomatizzato Indipendente dagli altri testFocalizzato single assertion testRobustoVeloce nellesecuzioneRipetibile

Eseguito frequentemente

Eseguito automaticamente

I test sono codice first classIl codice dei test fa parte del progetto e non meno importante del codice sottoposto a testI test vanno rifattorizzati e la qualit del codice deve essere tenuta alta necessario spendere tempo per creare buoni testAvere buoni test ripaga nel lungo termineFixtureFresh Fixture: ricreare le condizioni ad ogni testTransiente, al termine del test viene eliminataPersistente, rimane al termine del testShared Fixture: una stessa fixture viene riutilizzata per differenti test

Tutto ci che deve essere fatto per creare le precondizioni di test del SUT

Fixture Fresh TransientSetupExerciseVerifyTearDownFixtureGarbage CollectorFixture Fresh persistentSetupExerciseVerifyTearDownFixtureSetupExerciseVerifyTearDownFixtureTest non ripetibiliInterazione tra i test

Fixture CleanupSetupExerciseVerifyTearDownFixtureCleanup necessario rimuovere manualmente la fixture nel teardown

Fixture Cleanup LazySetupExerciseVerifyTearDownFixtureSetupExerciseVerifyTearDownFixtureCleanupSi pu posticipare la rimozione della fixture al momento in cui necessaria

Fixture Shared SetupExerciseVerifyTearDownFixtureExerciseVerifyTearDownExerciseVerifyTearDownLa fixture unica per una serie di testAumentare la velocit di esecuzioneRischio di interdipendenza

Asserzioni Single assertion TestLe asserzioni debbono essere chiareUsare nomi di test significativi

AsserzioniDelta Assertion: in caso di shared fixtureConfronti esterni: in caso di necessit di veirifica di molti dati (Es. File)Expected Object: Viene creato un oggetto che rappresenta il risultato attesoFavorire interfacce fluenti che rendono le asserzioni pi leggibiliUn piccolo esempioTest DoubleComponenti difficili da testare a causa di dipendenze (Database, altre librerie, etc)Componenti dipendenti da un ambiente esterno (network, webservice, etc)Test lenti a causa di interazione con componenti esterni poco performantiFIXTURETest DoubleSetupExerciseVerifyTearDownSUTDOCIl SUT dipende da un componente esterno DOC (Depend-on Component)Il DOC al di fuori del nostro controllo (Network, WebService) oppure semplicemente difficile da impostare (Database, FileSystem)Test DoublePer risolvere i problemi precedenti si pu sostituire il SUT con un componente fittizio, creato appositamente per il test, e denominato Test Double

FIXTURESetupExerciseVerifyTearDownSUTDOCTest DoubleDifferenti tiplogie di test doubleUn esempio di Test DoubleSi voglia testare un componente che, dati gli ordini dellultimo mese, esegua delle complesse regole di business e spedisca una mail a seconda del risultato.

FIXTURESetupExerciseVerifyTearDownSUTMailDBBack Door ManipulationAlternativo al test double, agire indirettametne sul SUT manipolando il DOCImpostare la fixture DataBase: Script di popolazioneDataBase: DataLoader File System: Creare i file di inputVerificare loutput del sut agendo sul DOCAsserzioni sul contenuto del DBConfronto di file con Expected ObjectTest di DatabaseTest di stored procedureTest del Data Access LayerTest dei mapping di un ORM Test di performance

Le problematiche maggiori dei test di Database sono collegate allimpostazione della fixture ed alla sua rimozioneI rischi sono di avere test erratici, non ripetibili, fragili e interdipendenti

Come gestire i test dei databaseEsempio di test di databaseCreazione del database di sandboxCreare un database in recovery mode simple (evita il transaction log)Copiare la struttura dal database master

Esempio di test di databaseCreare un preloader che funziona con bcp e BULK INSERTUtilizzare il TransactionScope per creare transazioni automaticheCreare singole classi di test raggruppate per Fixture, dove la fixture non altro che una serie di file con i dati da precaricareUtilizzare la gestione automatica delle transazioniEsempio di test di database

Il preload cancella tutto il contenuto di alcune tabelle e le precarica. Viene fatto allinizio del test e costituisce una Shared FixturePrima di ogni test viene creato un TransactionScope, tutto il codice che accede al db transazionaleNel TearDown del singolo test viene annullata ogni modifica effettuando il rollback della transazione.

Esempio di test su dbDesign for testabilityScrivere codice favorendo la possibilit di eseguire testUso intensivo di IoC e DISUTDOCDOCDOCDOCSUTDOCDOCDOCDOCIIIIDBLDBLDBLDBLDesign for testabilityTest di metodi privati

PRIVATEPROTECTEDTSSPROTECTEDPUBLICDesign for testabilityTest Driven Development

Red -> Green -> RefactorDomande??