La mia domanda è se dovrei testare il codice che so sarà cambiato in breve tempo. Sto facendo TDD in rubino, e spesso incontro questa domanda. Sono interessato alle migliori pratiche su questo, pro e contro. Grazie.
Aggiorna
Chiarimento: la mia domanda è fondamentalmente come si confronta il 'costo di scrivere un test' VS 'il fatto che il codice cambierà presto' e prendere una decisione.
Sì.
In questo modo sai che la tua modifica non ha infranto il codice.
Dovresti testare l'interfaccia / API in modo da poter cambiare i metodi sottostanti senza dover riscrivere i test. Quindi, quando i test diventano di nuovo verdi, sai che hai rifattorizzato / riscritto il codice con successo.
È possibile aggiungere nuovi test per testare la nuova funzionalità.
Sì, e soprattutto effettuare test che verranno eseguiti dopo le modifiche senza che sia necessario modificare il codice di test. Per ottenere questo, potresti mettere il codice probabilmente in grado di cambiare dietro un'interfaccia o avvolgerlo con qualcosa che lo deleghi se pensi che la sua struttura o la sua classe cambieranno.
Questa risposta presuppone che al momento sia presente un codice-A che fornisce una funzionalità. Sarà sostituito con il codice B che è abbastanza diverso ma fornisce anche la stessa funzionalità. Se è così, hai bisogno di test che testino il funzionamento di questa funzione e avrai bisogno di sforzarti per progettare / refactare codice-A correttamente in modo che possa essere modificato in codice-B senza che i test cambino.
Sicuramente se stai facendo TDD questa non è nemmeno una domanda?
Scrivi test per il codice prima di scrivere il codice - il gioco è fatto. Fatto (-:
Se il codice che vuoi cambiare non ha già i test allora sì, le cose sono improvvisamente un po 'più interessanti - idealmente comunque vuoi aggiungere test al codice che non è attualmente coperto in modo che quando è cambiato tu sia in grado di avere la certezza che quello che stai facendo non sta infrangendo le cose.
Infine c'è l'affermazione che "il codice cambierà presto" - quanto sei sicuro che ciò accadrà realmente? Questa è una domanda seria ... Ho avuto il codice che volevo cambiare / correggere per la parte migliore di 5 anni - per quanto cattivo (e alcuni di esso erano e altri bit erano solo) ha funzionato con vari gradi di adeguatezza e l'opportunità di cambiarlo non è mai sorto. (Ho il sospetto che fare test avrebbe aiutato a creare l'opportunità.)
Quanto cambierà il codice?
Se ti aspetti che il codice venga modificato un po ', allora avrebbe senso scrivere i test per il codice che hai modificato nello stesso momento in cui modifichi il tuo codice. Se il tuo codice è fondamentalmente destinato a essere gettato in un modo, probabilmente non vale la pena che tu scriva test per questo. Questo può essere complicato perché il codice di rinvio tende a trovarsi in produzione.
Questa è davvero una richiesta di giudizio da parte tua, dal momento che non esiste una checklist da cui lavorare. La mia ipotesi è che tu o qualcun altro abbia scritto il codice per un motivo, e se c'è del potenziale che non venga completamente riscritto o cestinato, scrivi i test. È una buona pratica.
Questo è molto soggettivo. Se stai parlando di sostituire le implementazioni, allora sono d'accordo, ha senso testare contro l'interfaccia. Se stai modificando l'interfaccia su cui stai programmando, allora personalmente terrò un todo / commento per ricordarmi di tornare ad esso e testarlo più tardi.
Direi ancora di sì, dovresti scrivere i test. Se sono solo gli algoritmi / la logica / struttura interni che cambieranno, i test potrebbero essere ancora dopo la modifica. Anche se il cambiamento sarà più sostanziale, i test ti ricorderanno quali erano le tue ipotesi nel progetto precedente e ti daranno consigli sulle cose che devi testare nel nuovo design. Potrebbe essere ancora necessario scrivere nuovi test (e magari rimuovere alcuni di quelli vecchi) dopo la modifica, ma sarà un processo prezioso da elaborare.