Inizierò il mio primo vero progetto in Ruby on Rails , e mi sto costringendo a scrivere test TDD . Non vedo reali vantaggi nella scrittura dei test, ma dal momento che sembra molto importante, ci proverò.
È necessario testare ogni parte della mia applicazione, incluse le pagine statiche?
TDD non parla di testing, ma di design. Scrivere i test ti costringe a pensare a come dovrebbe funzionare la classe ea quale tipo di interfaccia hai bisogno. I test sono un felice effetto collaterale che rende più facile il refactoring in seguito.
Quindi, tenendo presente questo, qual è il comportamento di una pagina statica e qual'è l'interfaccia?
La mia prima risposta sarebbe "none" e "none".
È sempre un'analisi costi-benefici. Qual è il costo della funzione che si sta rompendo? Se il costo è alto, prova bene e accuratamente. Se il costo è basso, prova leggermente o per niente.
C'è anche il costo del time-to-market da considerare. Forse è meglio per te fornire una funzionalità per lo più funzionante che non consegnare in ritardo una funzionalità completamente funzionante.
È quasi impossibile rispondere a queste domande nell'IMO generale.
Penso che sia più importante conservare la capacità di testare nel caso in cui alcune funzionalità risultino più importanti di quanto inizialmente realizzato.
Direi "sì". Se si dispone di test che coprono anche le funzioni e il codice più semplici, è possibile avere la certezza che l'aggiunta di un nuovo codice non causi il funzionamento del codice locale. Allo stesso modo, inserendo un test per ogni bug che si incontra, le regressioni si rimpiccioliscono.
Sì, dovresti testare tutto ...
Non sarà necessario essere in grado di scrivere test automatici per tutto. Per le tue pagine statiche, cerca di utilizzare il link di Selenium per assicurarti che le cose siano corrette.
Dalla mia esperienza, alcuni aspetti del front-end sono quasi impossibili da scrivere per i casi di test, ma è per questo che vorresti testare utilizzando il bulbo oculare Mark 1.
Il test è importante quanto la codifica. Devi sentire il detto "Se qualcosa può andare storto, lo sarà". INMO, Tra le molte tecniche di ingegneria del software che vengono impiegate per migliorare la qualità, il test è il più prezioso per aiutarti a trovare i problemi in anticipo.
Mentre testare tutto non è possibile (specialmente con team di piccole dimensioni e sistemi di grandi dimensioni), ciò non significa che si salti del tutto. Il test vale la pena? Vedi la sezione "Trovare i guasti in anticipo" in Wiki-SoftwareTesting .
I test TDD possono anche essere specifiche viventi se scritti in questo modo. I nomi dei metodi di test dovrebbero avere un senso per un utente aziendale.
Come altri hanno già detto, nel test di Ruby on Rails è molto più importante che nella (maggior parte) altre lingue. Ciò è dovuto alla mancanza di un compilatore.
Lingue come Delphi , C ++, VB.NET , ecc ... sono lingue compilate e il tuo compilatore raccoglierà molti mistkes come errori di battitura nelle chiamate a un metodo. In Ruby on Rails saprai solo se c'è un errore di battitura o un errore nel tuo codice se quella particolare riga di codice viene eseguita o stai utilizzando un IDE che mostra avvisi visivi.
Poiché OGNI singola riga di codice è importante (altrimenti non sarebbe lì), dovresti testare ogni metodo che scrivi. Questo è molto più semplice di quanto possa sembrare se si seguono alcuni strumenti di base di TBDD.
Ho trovato che Rails Cast di Ryan Bates su Come collaudo mi ha dato un valore inestimabile e ha davvero messo in luce la semplicità di TBDD se eseguito correttamente.
Se si sta veramente utilizzando la metodologia TDD, non si scrive codice senza prima aver effettuato un test unitario per il quale si sta tentando di eseguire il passaggio.
Direi di non iniziare con TDD. Prendi una decisione informata quando passi più tempo a imparare le strategie di architettura in generale. TDD non ti lascerà saltare i compiti, anche se potresti iniziare a crederci.
Ecco il mio problema. Quando dici che sembra un sacco di tempo sprecato per cose che non si romperanno mai, i TDDers ti diranno che ti apprezzeranno quando quell'unica cosa che non hai previsto in un'enorme catena di dipendenze viene sballata. Quando fai notare che è impossibile prevedere tali cose prima di scrivere la tua app, che è uh ... perché testiamo, ti dicono che è molto più sulla progettazione e non sui test anche se i test sono utili.
Ma le catene giganti di dipendenze collegate imprevedibili non sono il prodotto del design scadente?
Quindi qual è?
Ecco un pensiero. Non abbiamo enormi catene di dipendenze in primo luogo considerando i seguenti due principi di progettazione orientata agli oggetti da Design Pattern:
"Program to an interface, not an implementation"
Vale a dire, i tuoi oggetti non dovrebbero preoccuparsi di chi sta facendo la chiamata o di come sono stati fatti. Solo che gli argomenti appropriati sono stati nutriti e che i metodi che chiamano da altri oggetti sono diretti a funzionare come previsto. La catena di dipendenze nella maggior parte dei casi dovrebbe trovarsi a un punto di collegamento, la chiamata al metodo sulla parte del chiamante e il punto in cui gli argomenti vengono rilasciati nei metodi. È lì che accedi e convalidi e invii messaggi utili per il debug quando le cose vanno a pezzi.
E
"Favor object composition over class inheritance"
Chi è il manichino? Il tizio che ha fatto qualcosa in una classe in un complicato schema di successione a cascata che coinvolge come 30 classi con conseguente frazionamento del caso marginale, o lo sviluppatore che ha inventato quell'architettura in primo luogo? TDD potrebbe aiutarti ad arrivare al fondo delle questioni all'interno di quella torre pendente di classe Pisa prima di quanto potresti fare senza, ma ciò rende meno doloroso tentare di modificare uno degli endpoint di quel disastro di codice la prossima volta?
Ed è lì che arrivo alla cosa che mi infastidisce. TDD aiuta davvero a progettare o abilita una cattiva architettura? Mi sembra che abbia il potenziale per essere una strategia che si autoavvera. Più il tuo team non è responsabile della scarsa architettura, più utili saranno i componenti granulari di testing, ma alla fine la tua app diventa una PITA sempre più grande con cui lavorare (presupponendo che non abbiano mai pensato molto all'architettura nel primo posto). E l'incapacità di riconoscere le conseguenze di ciò è a portata di mano, sempre l'errore più costoso che si possa fare quando si lavora su un'applicazione che deve essere aggiornata e modificata nel tempo.
Per rispondere alla domanda, pensa a "cosa potrebbe andare storto qui". In particolare, se modifichi il "codice" (markup / qualunque), come avrai la certezza di non aver infranto la pagina. Bene, per una pagina statica:
Personalmente, consiglierei:
Il take away qui è che vuoi qualcosa di ripetibile, facile da usare e che verrà eseguito automaticamente nel tuo runner di prova.
Solo per aggiungere a tutte le risposte già eccellenti, ecco il mio modo di pensare su cosa testare e cosa non testare:
Fai test:
Non testare:
Quindi non ha senso fare un test che dice:
assert wibble = 3
e un codice che dice
wibble = 3
Inoltre, non è necessario testare le cose di presentazione, ad esempio se l'icona è in blu perywinkle, quale tipo di carattere hai utilizzato per le intestazioni e così via ...
Quindi, chiedi "dovrei testare le pagine statiche", e la risposta è: le verifichi nella misura in cui fanno parte delle funzionalità, della logica aziendale o del comportamento del tuo sito.
Quindi, nella nostra app, abbiamo un test che controlla che i termini & le condizioni sono disponibili da ogni parte del sito - per gli utenti anonimi, per gli utenti che hanno effettuato l'accesso, dalla dashboard, nelle schermate delle app ecc. Controlla semplicemente che c'è un collegamento chiamato "termini e condizioni" su ogni pagina, che il collegamento funziona , e poi il test dice che quando arriva sulla pagina, sembra "la Ts & Cs - quel tanto che basta per rassicurarti che è la pagina giusta, senza "testare una costante" o "testare la presentazione" ... così puoi controllare che il testo sia corretto, ad esempio, senza controllare la particolare dimensione del carattere o il layout del testo. ..