Ho alcune app che mi piacerebbe tornare indietro e creare retroattivamente una suite di test (RSpec & Cucumber), ma è un po 'scoraggiante iniziare questo processo.Rails: buon processo per aggiungere retroattivamente i test?
Quale sarebbe il processo per tornare indietro su un'app esistente e creare una suite di test per questo?
Recentemente ho iniziato ad aggiungere test a un gruppo di vecchi codici, e quello che ho trovato immensamente utile è rcov (non mi preoccupo del rcov plugin di rails e solo cd per testare ed eseguire un piccolo script di shell che esegue rcov con le giuste esclusioni e apre il report se tutti i test passano.) Poi, ho iniziato ad affrontare quelli che erano più vicini al 100% di copertura e semplicemente lavorando il percentuali a poco a poco. È un progresso molto più misurabile di "Ugh, da dove comincio con l'aggiunta di test per questo ?!"
Ottimo suggerimento e davvero utile! – Shpigford
Ultimamente lo sto facendo molto per progetti client. I blocchi più grandi per me sembrano essere l'uso sfrenato di javascript in linea con o senza RJS. [Nota a margine: c'è un modo giusto e sbagliato per fare AJAX, e la maggior parte delle persone si comporta male). Generalmente uso cetriolo pesantemente con un po 'di rspec per strani test di unità.
Le variabili da considerare sono diverse, ma un buon punto di partenza è con alcuni test di unità per i modelli. Crea alcune fabbriche e verifica le convalide, insieme a qualsiasi comportamento personalizzato che ritieni debba essere verificato.
Se non ci sei o se hai già una suite di test unitari e vuoi aggiungere integrazione, la prossima domanda è la misura in cui stai facendo un sacco di javascript o RJS in linea. Se la tua app è molto "ajaxy", dovrai iniziare con il driver del selenio per il cetriolo, che è lento come melassa a febbraio, ma riuscirà a completare il lavoro. Una volta che avrai una serie di test che coprono tutte le funzionalità (o anche solo le cose importanti) per la tua applicazione, inizierei a refactoring del javascript per funzionare in modo discreto.
Un'altra direzione si potrebbe andare sarebbe per costruire rspecs aggiuntive per i controller e punti di vista, ma non lo faccio piace molto questo modello, come si sta entrando testare l'implementazione al posto del funzionalità.
La cosa importante da ricordare è che non tutto deve accadere durante la notte. Analizza i tuoi flussi di lavoro (ad esempio, effettuando l'accesso, esegui l'attività A, esegui l'attività B, ecc.) E determina quali coprono l'80% dei casi d'uso tipici. Provali prima. Quindi usa qualcosa come metric_fu o semplicemente rcov (o qualsiasi altro strumento di copertura) e trova le aree del tuo codice che sono logiche e non testate. Mi piace metric_fu per questo perché la suite di strumenti che esegue può fornire entrambe queste informazioni.
Vorrei andare e aggiungere prima i test di alto livello (cetrioli). Questo ti darà la certezza che il comportamento non cambierà inosservato. Non andrei ad aggiungere i test di rspec (o forse solo alcuni di quelli imporanti) perché probabilmente vorrai fare anche un refactoring molto.
Quindi, eseguire metrics. MetricFu ha recentemente ottenuto una metrica chiamata "HotSpots", che combinerà altre metriche e ti indirizzerà ai più grandi problemi del codice. Questi posti sono solitamente anche i più critici per la tua applicazione. Risolvile appena sufficiente affinché sia leggibile e ottieni un buon senso di cosa si tratta. Non esagerare ancora.
Quindi, per ogni nuova funzionalità che si aggiungerà, aggiungere specifiche e pulire il codice con cui si sta interagendo. Quindi prova e ridefinisci le dipendenze delle nuove funzionalità, ma non andare oltre. Fallo in piccoli pezzi o perderai rapidamente la speranza.
Sono un po 'fuori tema qui, ma comunque ...
Penso unit testing di modelli in rotaie (3 almeno) è una specie di inutile ... mi riferisco soprattutto quando il codice è scritto , quindi non stai facendo TDD. Vuoi testare la tua convalida? Perché ? Basta leggere il codice e scoprirai gli errori da solo. Dico che le rotaie forniscono (in qualche luogo) una tale sintassi umana che sarebbe un peccato metterlo alla prova.
A mio parere, tale sintassi è a sua volta una specifica. Quindi, perché scrivere test?
E per essere chiari: No, non sto dicendo che i test sono inutili tutto il tempo. Non sto lavorando in qualche agenzia web casuale ...: p
Capisco il tuo punto di vista. Tuttavia, se non sei sicuro, aggiungi le specifiche. Se è il comportamento della tua applicazione, dovresti testarlo. E i modelli sono la parte principale della tua logica di business, quindi direi che la maggior parte dei test/specifiche delle unità sarebbe per i modelli. – iain
Infatti. Per riassumere il mio punto: se la sintassi del linguaggio è simile a quella di un business leggibile, allora perché testare? –
Per evitare regressioni, in cui il codice aggiuntivo che scrivi interrompe la vecchia funzionalità. A meno che non pianifichi di rileggere completamente il tuo codice ogni volta che apporti una modifica ... – Gareth
+1 perché mi stavo ponendo la stessa domanda –