Come assicurarsi che il codice funzioni ancora dopo il refactoring (linguaggio dinamico)

Question

Come assicurarsi che il codice funzioni ancora dopo il refactoring (cioè dopo il cambio di nome della variabile)?

In linguaggio statico, se una classe viene rinominata ma non è presente un'altra classe di riferimento, verrà visualizzato un errore di compilazione.

Ma in linguaggio dinamico non esiste tale rete di sicurezza e il codice può rompersi durante il refactoring se non si presta abbastanza attenzione allo. Puoi usare il test unitario, ma quando usi i mock è piuttosto difficile sapere che il nome cambia e, di conseguenza, potrebbe non essere d'aiuto.

Come risolvere questo problema?

Answer 1

Prima di iniziare il refactoring dovresti creare test che saranno in grado di testare ciò che cambierai - se dici che i test unitari non saranno sufficienti, o saranno difficili da creare, quindi creerai in ogni caso più in alto test di livello eventualmente anche excersising l'intero prodotto.

Se disponi di strumenti di copertura del codice per la tua lingua, utilizzali per misurare la qualità dei test che hai creato, dopo che ha raggiunto un valore ragionevolmente alto e se i test sono aggiornati e prolungati, sarai in grado di fare qualsiasi cosa con il tuo codice in modo molto efficiente ed essere piuttosto sicuro che le cose non vadano nella direzione sbagliata.

Answer 2

Il codice può rompersi durante il refactoring anche con una lingua compilata. Affidarti solo a questo ti mettere nei guai. Il test automatico è il modo migliore per assicurarsi che il programma funzioni come dovrebbe.

Se si dice quale linguaggio dinamico si sta utilizzando possiamo forse offrire alcuni consigli su strumenti che possono aiutare con il test. Tutto può essere testato

EDIT:

Hai risposto e ha detto di utilizzare PHP e Python.

Se questa è un'app Web, utilizzare selenium per creare i test nel browser. All'inizio ti serve solo l'IDE Selenium. Metti tutti i tuoi test in una singola Test Suite in modo da poterli eseguire facilmente tutti. Man mano che l'elenco cresce, puoi iniziare a esaminare il selenio RC e la griglia di selenio.

Answer 3

Ho insegnato a una lezione sui test unitari, sul refactoring e così via, e questa è probabilmente la cosa che la maggior parte delle persone sbaglia. Refactoring è non solo cambiando il codice. Sta cambiando il codice senza modificare il comportamento funzionale esterno. Questo è un punto molto importante.

In altre parole, è necessario disporre di un modo per verificare che il comportamento funzionale esterno sia intatto dopo il refactoring. Mancando di intuizione divina, trovo che i test unitari siano molto utili per questo. Nel suo libro sul Refactoring, Martin Fowler sottolinea l'uso di test automatici per questa verifica.

Se il codice è stato sviluppato utilizzando TDD, è necessario disporre della suite di test necessaria durante lo sviluppo del codice stesso. Se è necessario un codice refactoring per il quale non sono disponibili test, l'approccio migliore sarebbe quello di impostare test automatici prima di apportare eventuali modifiche al codice. Mi rendo conto che impostare i test per il codice esistente può essere difficile, ma imparerai molto sul codice mentre lo fai.

Si potrebbe anche voler controllare Bruce Eckel's essay on strong typing versus strong testing mentre si discute il feedback che si ottiene dal compilatore rispetto al feedback che si ottiene dalla propria suite di test.

Answer 4

1) Per Python utilizzare PyUnit per PHP phpunit. 2) L'approccio TDD è buono ma anche effettuare test dopo la scrittura del codice è accettabile. 3) Utilizzare anche strumenti di refactoring disponibili per l'IDE che fanno solo rifacimenti sicuri. In Python hai una corda (questa è una libreria ma ha plugin per la maggior parte degli IDE). 4) I buoni libri sono: 'Test-Driven Development con l'esempio' Best 'Expert Python Programmazione' Tarek Ziade (spiegare sia TDD e refactoring)

google TDD e database per trovare un buon libro su approccio TDD per lo sviluppo banche dati.

Aggiungi informazioni per i mock che stai utilizzando. I mock AFAIK sono necessari solo quando sono coinvolti il ​​database o la rete. Ma normalmente il test unitario dovrebbe coprire un piccolo codice di codice (solo una classe) a volte due classi quindi non è necessario il mockup !!