Refactoring e Test GBerio
Migliorare la codifica: il refactoring Metodo strutturato e disciplinato per riscrivere o modificare il codice prodotto Tali riscritture o modifiche devono avvenire nell’ipotesi di non alterare il comportamento del codice Il refactoring può essere combinato, in modo sistematico, con il test di regressione
Esempio di refactoring Extract methodTrasforma un metodo lungo in uno equivalente più breve estraendo una parte ed inglobandola in un metodo privato
Test
Obiettivi del test e UP In generale: “trovare i difetti” UP: test unità e codifica insieme cioè definiti i casi test d’unità (cioè di classi) si implementa il codice su cui eseguire i casi, quindi si eseguono i casi (TDD, Test Driven Development) Si passa quindi a test d’integrazione usando un concetti simile a quelli introdotti con i moduli (ad esempio, le dipendenze date dalle associazioni, con la navigabilità, nel diagramma delle classi indicano come fare un test d’integrazione “bottom-up”) Il TDD è quindi tipicamente black-box e si applica a metodi singoli (dotati di pre/post condizioni)ovvero a sequenze di metodi identificate attraverso diagrammi d’interazione Il test white box si può sempre applicare ai metodi, soprattutto singoli, ed al loro codice, in seguito
Test delle operazioni Per ogni operazione è possibile definire un test white box e/o black box Vi sono sequenze di operazioni (anche la medesima eseguita più volte) che devono eventualmente dare luogo ad alcune post-condizioni: –Casuali –Partizione degli attributi (coprire almeno una volta tutti gli attributi) –Collaborazioni (coprire almeno un volta tutti i cammini della collaborazione) –Statechart (coprire almeno una volta ogni stato)
Associazioni come Dipendenze