![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (17)
Semelhante a Testing
Semelhante a Testing (20)
Mais de Domenico Briganti
Mais de Domenico Briganti (7)
Último
Último (9)
Testing
- 1. Testing Test Driver Development Design Improvement alias Refactoring Continuous Integration e altre pratiche Domenico Briganti 14/06/2006
- 16. Costo di un bug e “località” Fonte: http://www.dia.uniroma3.it/~merialdo/didattica/aa2005-2006/poo/trasparenze/POO-17-testing-tecniche.ppt
- 31. Passaggio di parametri al tests <junit printsummary="no”… <sysproperty key="docs.dir” file="${test.dir}”/> <sysproperty key="index.dir” file="${test.dir}/index”/> … </junit> private String docsDir = System.getProperty("docs.dir"); private String indexDir = System.getProperty("index.dir");
- 32. TestRunners con swing (SwingUI)
- 35. Report del test
- 45. Ciclo di build di C.I. VCS Build Artifacts Dir Mail/Sound/Light… 1. Bootstrap 2. Check for modifications 3. Get the revision log Cruise Control Your project’s Build file Ant, Maven, Make 2. Run Build 5. Publish Artifacts 6. Send to publisher 1. Get the latest source 3. Tag source (optional) Project Specific Adapter - Ant Script 4. Run Build
- 50. Di cosa abbiamo parlato...
Notas do Editor
- Trovare e correggere un problema software dopo la consegna è 100 volte più costoso che nelle fasi di raccolta requisiti e early design.
- Quando un test funziona? Quando fallisce! TDD è una delle pratiche che si usano durante lo sviluppo in un team XP. Le altre sono: Whole Team Planning Game Customer Tests Small Releases Simple Design Pair Programming Refactoring Continuos Integration Collective Code Ownerschip Coding Standard Metaphor Sustainable Pace http://www.xprogramming.com/xpmag/whatisxp.htm
- Coesione La coesione fa riferimento al numero e alla eterogeneità dei compiti di cui una singola unità è responsabile Se ciascuna unità è responsabile di un singolo compito, diciamo che tale unità ha una alta coesione La coesione si applica alle classi e ai metodi Noi puntiamo ad una alta coesione Un’alta coesione rende più semplice: Capire ciò che fa una classe o un metodo L’uso di nomi appropriati Il riuso delle classi e dei metodi Coesione dei metodi Un metodo dovrebbe essere responsabile di un solo compito ben definito Coesione delle classi Ogni classe dovrebbe rappresentare una singola entità ben definita Accoppiamento L’accoppiamento si riferisce ai legami tra unità separate di un programma Se due classi dipendono strettamente per molti dettagli l’una dall’altra, diciamo che sono strettamente accoppiate Per un codice di qualità dobbiamo puntare ad un basso accoppiamento Un basso accoppiamento permette di: Capire il codice di una classe senza leggere i dettagli delle altre Modificare una classe senza che le modifiche abbiano impatti sulle altre classi Quindi un basso accoppiamento migliora la manutenibilità del software
- La manutenzione del software spesso richiede l’aggiunta di nuovo codice Le classi e i metodi tendono così a diventare più lunghi, a perdere in coesione e ad aumentare l’accoppiamento A seguito delle modifiche, per mantenere un’alta coesione ed un basso accoppiamento classi e metodi dovranno essere riorganizzate Questo processo di riorganizzazione del codice viene definito “ refactoring ”
- Per mantenere il codice pulito e con un eccellente design abbiamo visto che dobbiamo attenerci ai due parametri principali Basso accoppiamento e alta coesione. Questo significa che dobbiamo rifattorizzare spesso, mantenendo un ottimo design del codice, ma rischiamo di inserire malfunzionamenti dovute alle modifiche. Le suite di test ci proteggono dalla regressione. Controllando ad ogni loro avvio (diverse volte durante la modifica al codice) che il tutto continui a funzionare correttamente.
- Regression Test: Qual è la prima cosa da fare quando un bug viene segnalato? Scrivere il test più semplice possibile che fallisce segnalandolo.
- Dal fallimento di un test alla rimozione dell’errore deve trascorre pochissimo tempo grazie alla località errori...
- “ altrimenti barre rosse” significa che il giorno dopo sai da dove riprendere a lavorare, ma solo se non si è in team! Inoltre “...devi avere 2 problemi…” è essenziale dato che stiamo parlando di unit test, quindi test a livello di classe e isolati tra loro
- Nonexecution-Based Testing walk-through Ispezione diretta del codice Cleanroom Nel ciclo di vita incrementale, letture e controlli di qualità del codice. Verifica di correttezza tecniche formali logico-matematiche Execution-Based Testing testing rispetto alle specifiche ( black box testing ) Considera i requisiti nel derivare i test case Non considera la struttura del software testing to code ( white box testing ) test case basati sul codice Considera la struttura del software nel derivare i test case Valutato in termini di coverage (statements, branches, paths, etc.)
- A set of assert methods. Messages are only displayed when an assert fails.
- Haltonfailute evitarli perchè se c’è un fail durante I test, il buil si blocca con il messaggio “Buil Failed” errorproperty e failureproperty impostano il valore della variabile contenuta a true per far scattare il <fail> sotto <Fail> stampa un messaggio di errore sulla console dopo l’esecuzione di un test fallito
- Integrare giornalmente significa ridurre drasticamente il rischio di blocchi e incoerenze più radicali tra le parti software.
- Executes every “n” seconds or schedulable at particular times. The process: Bootstrap (setup) Check for modifications Run build Publish results