UNIVERSITA’ DEGLI STUDI DI BARI LAUREA SPECIALISTICA IN INFORMATICA “SISTEMI PER LA COLLABORAZIONE IN RETE” REFACTORING Casi di test del caso d’uso “Select Team” della fase Planning dell’applicazione IBIS Docente: Filippo Lanubile Studente: Alessio Angelini

INTRODUZIONE IBIS (Internet-Based Inspection System): l’applicazione è un sistema di supporto alle ispezioni basato su un architettura Asp.Net Caso d’uso “Select Team”: permette di assegnare un team di ispettori ad una determinata ispezione Refactoring: individuare casi di test relativi al caso d’uso, analizzarli e verificarne la correttezza

REFACTORING Classi e metodi selezionati per il caso d’uso “Select Team”:  Service.UserService (getUserIdList)  Service.PlanningService (loadInspectionTeam,saveInspectionTeam,updateInspector)  DomainModel.User (getUsersRegistered)  DomainModel.InspectionTeam (getInspectors,findInspectorByUserId,addInspector,removeIn spector)  DomainModel.Inspector (addInspector)  DataMapper.UserMapper (findAll)  DataMapper.InspectorMapper (findAll,insert,delete)

REFACTORING Casi di test selezionati per l’analisi:  DataMapperTest.InspectorMapperTest.insertTest  DataMapperTest.InspectorMapperTest.deleteTest  DataMapperTest.InspectorMapperTest.findAllTest  DomainModelTest.InspectionTeamTest.addInspectorTest  DomainModelTest.InspectionTeamTest.removeInspectorTe st  DomainModelTest.InspectionTeamTest.findInspectorByUse rIdTest  DomainModelTest.InspectionTeamTest.getInspectorsTest

ANALISI DEI CASI DI TEST ClasseMetodoPrincipi violati DataMapperTest.InspectorMapperTestinsertTestb, e, j, k DataMapperTest.InspectorMapperTestdeleteTestb, j, k DataMapperTest.InspectorMapperTestfindAlle, h, j, k DomainModelTest.InspectionTeamTestaddInspectore, h, j, k DomainModelTest.InspectionTeamTestremoveInspectore, h, j, k DomainModelTest.InspectionTeamTestfindInspectorByUserIde, h, j, k DomainModelTest.InspectionTeamTestgetInspectorsh, j, k

PRINCIPI VIOLATI b: il sistema viene modificato (insertTest, deleteTest) e: non vengono testati i diversi scenari possibili h: il metodo non è indipendente dai dati del sistema j: il codice non rispetta la struttura a 4 fasi (Setup,Exercise,Verify,Teardown) k: il codice non è facile da leggere ed è poco comprensibile

MODIFICHE ADOTTATE Riorganizzazione del codice con la struttura a 4 fasi (principio j) Ordinamento del codice in modo da renderlo più comprensibile (principio k) Verifica degli scenari possibili più importanti (principio e) Usare dati indipendenti dal sistema, ad esempio ispezione apposita “inspectionTest” (principio h) Quando viene modificato il sistema riportare tutto nella situazione originale tramite la fase di Teardown (principio b)

TEST MANCANTI Service.PlanningService.saveInspectionTeam: il test è mancante ma comunque necessario quindi è stato creato appositamente Il test è necessario perché il metodo effettua il salvataggio dei dati degli ispettori, in particolare bisogna testare il caso in cui vengono fatte delle modifiche ai dati di un ispettore