Tests:Your Life Insurance! Migration Strategies

1. Università degli Studi di Milano Bicocca – Laurea Magistrale in Informatica Corso di Evoluzione Sistemi Software e Reverse Engineering 2008/2009 – Prof.ssa Arcelli Object Oriented Reenginnering Pattern Tests:Your Life Insurance!Migration Strategies Carella Carmine Faustinoni Fabrizio Falco Giuseppe Passoni Alberto Riferimenti: Object Oriented Reenginnering Pattern - S.Demeyer, S.Ducasse, O.Nierstrasz, 2008. 1

2. Tests: Your Life Insurance! Il tema principale del cluster è: l’utilizzo di strategie di testing nel contesto della reingegnerizzazione per ridurre i rischi del processo di cambiamento di un sistema legacy critico per il business aziendale. N.B: le strategie di testing presentate non sono le uniche possibili, ma quelle più rilevanti nel caso di un progetto di reengineering. 2

3. Pattern che compongono il cluster e loro relazioni: Tests: You Life Insurance! 3

4. Write Test to Enable Evolution OBIETTIVO: proteggere il valore del legacy system attraverso un testing sistematico. PROBLEMA: minimizzare i rischi in un processo di reengineering. Modificare un legacy è rischioso per il business. Quali Rischi? • Non soddisfare l’obiettivo del reengineering; (miglioramento legacy system  evoluzione)‏ • Introdurre ulteriore complessità nel sistema; • Compromettere le funzionalità critiche per il business; • Intraprendere una strada sbagliata: troppi sforzi per un task che non è quello designato; • Aumentare ulteriormente i costi di mantenimento. Tests: You Life Insurance! 4

5. Write Test to Enable Evolution Problema Difficile perché: • La valutazione dei cambiamenti non sempre è possibile • Test non sempre è applicabile • componenti non comprese perché non documentate  test progettato male • Dipendenze nascoste, destabilizzano il sistema. Problema risolvibile • Sistema in esecuzione e si determina cosa funziona e non funziona • Sono note le parti del sistema stabili e quelle soggette a cambiamenti Soluzione • Un processo di testing basato su test ben progettati. (Well-designed test)‏ Tests: You Life Insurance! 5

6. Well-Designed test – proprietà • Automatico: test eseguiti senza intervento umano. Test pienamente automatici. • Persistente: un test, per essere automatico deve essere memorizzato. Memorizzare i dati del test, le azioni da eseguire e il risultato atteso. • Documentazione del sistema; • Soggetto a controllo delle versioni, come altro codice; • Ripetibile: dopo ogni implementazione di un cambiamento il test deve essere rieseguito. Data una nuova funzionalità deve esser possibile aggiungere facilmente nuovi test tra quelli esistenti (test suite). • Unit testing: i test dovrebbero essere associati a componenti software atomiche , per identificare chiaramente quali parti testano e ridurre la complessità del test. • Indipendente: minimizzare le dipendenze con gli altri test per evitare “effetto a cascata”. Il numero di test falliti deve essere un indicatore del numero di problemi rilevati. Tests: You Life Insurance! 6

7. Write Test to Enable Evolution Vantaggi: • I test aumentano la fiducia nel sistema e favoriscono cambiamenti sicuri permettendo l’evoluzione. • Documenti di test come artifacts di un sistema. Descrizione del sistema sempre aggiornata, rispetto alla documentazione scritta. • Framework di supporto esistono per tutti i principali linguaggi object oriented (Smalltalk, Java C++). Svantaggi: • Allocare risorse umane per scrivere i test • I test dimostrano solo la presenza di difetti, non li risolvono. • È impossibile coprire con i test tutti gli aspetti di un sistema legacy • Test progettati male: il test viene eseguito si pensa tutto va bene, ma in realtà non sta testando il comportamento desiderato. Tests: You Life Insurance! 7

8. Write Test to Enable Evolution Difficoltà: • Troppi approcci di testing esistenti. Scelta dell’approccio più adatto. • Legacy system grandi e non documentati  testing proibitivo • Management è restio nell’investire nel testing. • Convincere gli sviluppatori ad adottare il testing: mostrare come il testing non solo velocizza lo sviluppo ma anche l’attività di mantenimento • Il testing può essere un attività noiosa: utilizzo del toll di supporto più adatto. Tests: You Life Insurance! 8

9. Write Test to Enable Evolution Conclusioni: • I test rappresentano una forma tangibile di fiducia nel sistema, perché permettono di verificare che il sistema sia corretto e possono essere eseguiti quando si vuole per verificarne la consistenza. • I test sono la base per il reengineering. Attività di Mantenimento documentazione Evoluzione Architetturale Fiducia nel sistema Riduzione dei rischi Fiducia nei cambiamenti al sistema Tests Automatici Tests: You Life Insurance! 9

10. Write Test to Enable Evolution Relazioni con altri pattern: • Always have a running version • Migrate system incrementally • Grow your test base incrementally • Test the interface, not the implementation Tests: You Life Insurance! 10

11. Grow Your Test Base Incrementally OBIETTIVO: bilanciare i costi e i benefici dei test, introducendoli incrementalmente solo quando necessario. Tests: You Life Insurance! 11

12. Grow Your Test Base Incrementally Problematiche: • Progettazione dei casi di test occupa una notevole quantità di tempo  quando fermarmi nel costruire casi di test? • Impossibile testare tutte le parti che compongono un legacy system data la loro grandezza e complessità • I programmatori che hanno realizzato il sw non sono più reperibili e quindi le conoscenze del legacy sono limitate. Soluzione: • Introdurre i test incrementalmente, solo per quelle parti del sistema su cui stiamo lavorando Tests: You Life Insurance! 12

13. Grow Your Test Base Incrementally Suggerimenti: • Sviluppare i casi di test nel seguente ordine: • Inizialmente solo per le componenti più critiche e con priorità più alta. • Per le nuove funzionalità create durante la fase di reengineering. • Per le parti che presentano bug importanti. • Se si ha una storia dei vecchi bug risolti, usare i vecchi Test bug come punto di partenza. • Testare le interfacce e non l’implementazione, iniziando dalle grandi gerarchie di astrazione e, se avanza tempo, testare singolarmente le parti. Tests: You Life Insurance! 13

14. Grow Your Test Base Incrementally Vantaggi: • Risparmi del tempo (in quanto si sviluppano solo i test necessari). • Costruzione di test per le parti più critiche del sistema. • Agevolazione dello sviluppo di funzionalità future e del mantenimento. Svantaggi: • Errori nell’individuazione degli aspetti critici del sistema  tempo e risorse sprecate. • I test possono dare troppa fiducia in quanto possono ancora nascondersi bug importanti nel codice. Tests: You Life Insurance! 14

15. Individuare il sottosistema da modificare (ABC)‏ Introdurre i test solo per il sottosistema ABC e per la componente B Applicare i test alla nuova componente B Tests: You Life Insurance! 15

16. Grow Your Test Base Incrementally CONCLUSIONI: • Una strategia di test incrementale consente di iniziare il processo di reengineering prima di aver sviluppato tutti i test. • Minimo investimento di risorse nella fase di test in quanto questa fase è concentrata solo su quelle parti che si intendono modificare e non su tutto il sistema. Tests: You Life Insurance! 16

17. Use a testing framework OBIETTIVO: Incoraggiare gli sviluppatori a scrivere ed utilizzare i test di regressione, fornendo un framework che ne renda facile lo sviluppo, l’organizzazione e l’esecuzione. PROBLEMA – Come incoraggiare il team a fare testing? Problema Difficoltoso : - i test sono noiosi da creare; - richiedono la creazione di dati ad-hoc per essere effettuati; - è difficile capire la differenza tra un test fallito ed un unexpected error. Tests: You Life Insurance! 17

18. Use a testing framework LA SOLUZIONE E’ FATTIBILE: - I test (la maggior parte) seguono lo stesso pattern CREAZIONE DATI DI PROVA ESECUZIONE DI ALCUNE AZIONI VERIFICA ESITO - l’infrastruttura per eseguire i test è semplice QUINDI… Utilizzare un framework di testing che consenta di comporre una test suite a partire da test case specifici Tests: You Life Insurance! 18

19. Use a testing framework POSSIBILE PROBLEMA: - Non esiste un framework di test per il linguaggio che si sta utilizzando NIENTE PAURA! Combinare le informazioni che si possiedono in accordo con i seguenti principi: - L’utente fornirà casi prova utilizzabili come test e fornirà asserzioni sui risultati; - Il framework fornisce un feedback in caso di successo - insuccesso del test INDICA PRECISAMENTE IL TEST CHE E’ FALLITO GLI ERRORI DEVONO ESSERE COLLOCATI IN UN REPORT - Il framework consente la creazione di test suite Tests: You Life Insurance! 19

20. Use a testing framework PRO: Un framework per i test semplifica la formulazione dei test ed invoglia i programmatori ad effettuarli. CONS: La fase di test richiede impegno, disciplina e supporto;E’ difficoltoso convincere il team dell’utilità del testing; E’ complicato inserire la fase di test all’interno del processo di sviluppo di un team che non l’ha mai considerata. Tests: You Life Insurance! 20

21. Use a testing framework ESEMPI: Junit (test framework for Java)‏ - I test sono definiti come sottoclassi di TestCase - Utente deve definire i metodi setUp(), runTest() e tearDown()‏ - Gli errori sono gestiti e segnalati mediante l’utilizzo della classe TestResult - TestCase fornisce metodi standard come assertEquals e asserdFails - I test possono essere inseriti all’interno di una TestSuite ESISTONO FRAMEWORK DI TEST SPECIFICI PER OGNI TIPO DI LINGUAGGIO: Ada, ANT, C, C++, Delphi, .Net (all languages), Eiffel, Forte 4GL, GemStone/S, Jade, JUnit Java, JavaScript, k language (ksql, from kbd), Objective C, Open Road (CA), Oracle, PalmUnit, Perl, PhpUnit, PowerBuilder, Python, Rebol, ‘Ruby, Smalltalk, Visual Objects and UVisual Basic. Tests: You Life Insurance! 21

22. Test the Interface, Not the Implementation OBIETTIVO: costruire test riusabili che non si focalizzino sui dettagli di implementazione, ma piuttosto su comportamenti esterni, per sopravvivere ai cambiamenti del sistema PROBLEMA: Sviluppare test che siano resistenti nel tempo ai cambiamenti della componente a cui sono legati. Problema difficile perché: • mentre evolve, il legacy system deve continuare a supportare il processo di business; • non si può perdere troppo tempo nella scrittura dei test; • non impiegare troppe energie per scrivere test che diventeranno presto obsoleti. Tests: You Life Insurance! 22

23. Test the Interface, Not the Implementation Problema risolvibile: • Le interfacce dei componenti dicono cosa deve esser testato • Le interfecce tendono a essere più stabili dell’implementazione. Soluzione: • Sviluppare test di tipo black-box che sfruttano le interfacce pubbliche delle componenti. • Costruire la soluzione: • Come dati di test utilizzare valori estremi (minimo e massimo); • Se ci sono molte componenti fine-grained utilizzare una strategia top-down per sviluppare i test; • Se si sta modificando una funzionalità ben precisa utilizzare una strategia bottom-up per testarla. Tests: You Life Insurance! 23

24. Test the Interface, Not the Implementation Vantaggi: • Se l’implementazione cambia è poco probabile che la sua interfaccia subisca modifiche  test sull’interfaccia è più riusabile; • Black-box tests possono essere usati per più implementazioni della stessa interfaccia; • I test sulle interfacce sono più semplici da realizzare; • Evita di scrivere i test troppo presto; Svantaggi: • I Black-box test non coprono tutto il codice; • Se l’interfaccia cambia, bisogna modificare il test; • La classe non fornisce la giusta interfaccia per l’applicazione delblack-box test, allora altre strategie di testing (white-box testing). Tests: You Life Insurance! 24

25. Test the Interface, Not the Implementation Conclusioni: • Le interfacce di un componente, sono una conseguenza della sua interazione con altre componenti; il black-box test può essere utile nel verificare le principali interazioni di un sistema • Black-box test hanno maggiori probabilità di sopravvivere ai cambiamenti del sistema, perché le interfacce tendono ad essere più stabili. Relazioni con altri pattern: • Record business rule as tests. Tests: You Life Insurance! 25

26. Record Business Rules as Tests OBIETTIVO: Mantenere il sistema al passo con le regole di business da esso implementate codificandole come Test. Tests: You Life Insurance! 26

27. Record Business Rules as Tests Problematiche: • La documentazione spesso non contiene i dati relativi ai piani business • Regole business spesso sono implicite nel codice • Il cambiamento degli sviluppatori provoca l’aumento dei rischi • Cambiamento per fattori esterni • Risoluzione problematica semplice poiché le regole business seguono delle linee guida Tests: You Life Insurance! 27

28. Record Business Rules as Tests Soluzione: • Scrivere test eseguibili che registrano gli affari come casi di test. • Gli sviluppatori scrivono i test funzionali • I clienti scrivono i test di integrazione Tests: You Life Insurance! 28

29. Record Business Rules as Tests Vantaggi: • Regole esplicite, riduzione dipendenza umana • Prima di effettuare la reingegnerizzazione del legacy system si devono registrare le regole business • Permette l’evoluzione delle regole business: aggiunta di nuove features e test di regressione per verificare la loro correttezza Tests: You Life Insurance! 29

30. Record Business Rules as Tests Svantaggi: • I test codificano solo eventi concreti • La logica business prevede molti casi, ma non tutti vengono trattati • Registrare business rules non significa estrarre business rules. L’estrazione con la corrente tecnologia è ancora un sogno. • Registrare business rules è difficile se cambia il team Tests: You Life Insurance! 30

31. Record Business Rules as Tests Conclusioni: • I test sono un buon metodo per documentare ciò che il sistema fa. • Documentando i business rules come test, posso garantire la descrizione di esso durante l’implementazione Tests: You Life Insurance! 31

32. Write Test To Understand Obiettivo Registrazione della comprensione di parte del codice sotto forma di test eseguibili, in modo da essere utili quando si modificherà il sistema in futuro Tests: You Life Insurance! 32

33. Write Test To Understand Problematiche • Codice non sempre comprensibile • Ipotesi su quello che il codice fa e validazione di tali ipotesi • Specificare il comportamento del sistema • Documentazione obsoleta appena si cambia il codice Tests: You Life Insurance! 33

34. Write Test To Understand Soluzione • Codificare ipotesi e conclusioni come test eseguibili Tests: You Life Insurance! 34

35. Write Test To Understand Vantaggi • I test aiutano la comprensione • I test offrono specifiche precise di certi aspetti del sistema • I test sono applicati a diversi livelli di comprensione • I test sviluppati aiuteranno il futuro reengineering • Maggiore precisione nella creazione e uso dell’oggetto Tests: You Life Insurance! 35

36. Write Test To Understand Svantaggi • Scrivere test comporta la perdita di tempo • Oggetti testati non hanno un’astrazione • Non va bene per processi concorrenti Tests: You Life Insurance! 36

37. Write Test To Understand Conclusioni • Per scrivere test automatici bisogna partite dal sistema preso in considerazione e capirlo • Registrazione per settare il piano per una futura re-ingegnerizzazione Tests: You Life Insurance! 37

38. Migration Strategies Migration Strategies

39. Migration Strategies Migration Strategies Introduzione Dopo i test la reingegnerizzazione è a buon punto, si ha una buona conoscenza del sistema legacy e si sono scritti i test che iniziano la fase di evoluzione. Domande • Siamo sicuri che il nuovo sistema sarà accettato? • Come migrare verso il nuovo sistema nonostante quello vecchio sia ancora in uso? • Si può testare il nuovo sistema prima che sia pronto?

40. Migration Strategies Migration Strategies Punti chiave: • Migrazione Big-bang rischiosa • Troppe modifiche creano confusione negli utenti • Feedback • Gli utenti devono fare il loro lavoro, ma non vogliono essere distratti da soluzioni incomplete • Data legacy devono rimanere intatti Panoramica Il reengineering non è sufficiente, bisogna introdurre la migrazione graduale verso un nuovo sistema in modo da essere indolore agli utenti.

41. Migration Strategies Migration Strategies

42. Migration Strategies Involve The User System • Obiettivo: massimizzare il numero di cambiamenti coinvolgendo l'utente a ogni step

43. Migration Strategies Involve The User System Problematiche: • I sistemi sono vecchi. Gli utenti vogliono sapere come funziona e come aggirare i problemi. • La gente odia il dover imparare qualcosa di nuovo a meno che non sia qualcosa di semplice • La percezione dell'utente di ciò che è necessario per migliorare un sistema. • Gli utenti possono avere difficoltà a valutare un documento di progettazione. • E‘ difficile essere entusiasti di un nuovo sistema che non è pronto per l'uso.

44. Migration Strategies Involve The User System Soluzione: Coinvolgere direttamente gli utenti e tenerli aggiornati sul sistema. Passi: • chiedere agli utenti le priorità. • dividere le priorità in fasi. • utenti e sviluppatori si devono tenere in contatto. • avere dei feedback sulle versioni intermedie.

45. Migration Strategies Involve The User System Vantaggi: • I requisiti devono essere aggiornati e validati spesso, per andare verso il risultato sperato • Se gli utenti hanno la sensazione d'essere utile per ottenere i risultati saranno invogliati a lasciare feedback positivi • Gli utenti saranno coinvolti durante lo svolgimento del progetto, eliminando il successivo periodo di formazione

46. Migration Strategies Involve The User System Svantaggi: • Gli sviluppatori possono avvertire gli utenti che il loro coinvolgimento può distrarre dal lavoro di reingegnerizzazione del sistema. • Aumento delle aspettative e mettere pressione supplementare sul vostro team. • Può essere difficile coinvolgere gli utenti • Non è possibile coinvolgere tutti, e gli utenti che sono lasciati fuori potrebbero sentirsi trascurati

47. Migration Strategies Involve The User System Conclusioni: • Si utilizzano i feedback per assicurare che si stanno affrontando le reali esigenze del cliente.

48. Migration Strategies Build confidence Obiettivo: • aumentare le chances di avere successo attraverso risultati dimostrativi a ogni fase.

49. Migration Strategies Build confidence Problematiche • Alcuni progetti vogliono dei requisiti e devono rientrare in un badget. • Gli utenti raramente dicono ciò che realmente vogliono • Difficoltà nel convincere gli utenti sui legacy system

50. Migration Strategies Build confidence Soluzione: • creare un atmosfera positiva per dimostrare che molti risultati positivi sono ottenibili grazie a questo clima Fasi: • Suddividere il lavoro in piccoli step per avere il più presto possibile un nuovo risultato