Come faresti un blog con un approccio TDD?

Question

Sto considerando di rifare il mio blog (attualmente in PHP, ma < 100 righe di codice non di layout) in Ruby on Rails solo per il gusto di farlo. Voglio fare un altro progetto in Rails, ma dovrei imparare Rails (più di Hello World) prima di provare a creare un progetto completo.

Un'altra cosa che voglio fare mentre rema il mio blog è di capire almeno che cosa sia TDD. Quindi, come faresti ad adottare un approccio Test Driven alla creazione di un blog? Quali test vorresti scrivere? Come cominceresti?

Ogni volta che visualizzo scrivendo un blog finirebbe per avere bisogno di un milione di test per un singolo componente per testarlo completamente. Come evitare di scrivere troppi test?

Inoltre, sto facendo questo wiki comunità perché ho intenzione per questo di fondamentalmente essere trasformato in un mini base di tutorial/conoscenze ...

sono andato avanti e messo una taglia su questa questione così forse posso effettivamente ottenere una buona risposta a questo ..

Answer 1

TDD è più di progettazione, si tratta di test. A molte persone manca questo e finirà per praticare qualcosa che non sembra proprio TDD. Con TDD, stai scrivendo un test per guidare un cambiamento nel tuo codice. Non dovresti preoccuparti di scrivere troppi test, perché dovresti avere solo un test da scrivere se c'è più codice di produzione da scrivere (e quindi più codice da testare). Di nuovo, TDD NON sta semplicemente scrivendo molti test per il tuo codice, ma finirai con un sacco di test e, quindi, avrai una potente suite di test per darti feedback man mano che il tuo codice cresce e cambia.

Piuttosto che parlare di come testare lo sviluppo di qualche particolare software, ti consiglio di leggere e imparare come praticare il TDD e capire, come hai detto, di cosa si tratta. Un buon libro da considerare è: Growing Object Oriented Software, Guided by Tests. Il libro usa Java, ma è una grande applicazione reale dell'uso di TDD per creare un software abbastanza complesso.

C'è molto per TDD, e consiglierei di scavare in alcune buone fonti se vuoi imparare e provare a praticarlo perché c'è più di quanto possa essere sollevato in risposta a questa domanda.

Answer 2

Iniziare scrivendo le funzioni Cucumber per fornire una copertura "esterna". Questi dovrebbero essere in grado di testare la maggior parte delle funzionalità da soli. Molto facile da scrivere. Un blog non ha tanti test, dopotutto sono solo post e commenti, giusto? Dai un'occhiata alla mia applicazione blorgh che è un'app Rails sviluppata usando Cucumber.

Answer 3

Interessante, questo è esattamente quello che ho iniziato un paio di giorni fa. Sto usando RSpec e Cucumber. Ho iniziato scrivendo un paio di specifiche per i modelli Article e Comment. Quando sono diventati verdi ho scritto i test di Cetriolo per implementare viste, controller, ecc.

Questo funziona davvero bene per me, ma immagino che iniziare con Cucumber sia positivo, visto che molti sembrano apprezzare questo approccio.

Nel caso in cui si hanno solo poche conoscenze di RSpec e cetriolo mi raccomando Railscasts:

• Beginning with Cucumber
• More on Cucumber
• Testing Controllers with RSpec
• RSpec Matchers & Macros

Ho apprezzato anche la Peepcode screencast ma a differenza dei railscast costano 9 $ ciascuno.

Answer 4

Dai un'occhiata agli stakeholder e cosa vogliono ottenere. È importante iniziare da lì, perché ti consente di dare la priorità correttamente (cioè non sulla parte tecnica più interessante, ma sulla parte con il valore più aziendale). Lo sviluppatore è uno stakeholder, e ridurre i suoi timori (di non essere in grado di costruire qualcosa) è un obiettivo valido.

Il pensiero sul design viene scritto nei test. Inizia con gli obiettivi finali delle parti interessate, lavora da lì all'indietro fino all'inizio (inversione del tempo). Ciò garantisce che ti concentri su cosa e meno su come. L'interazione tra oggetti è più importante per ottenere il diritto rispetto agli attributi dell'oggetto.

Vedi:

• http://www.robvens.nl/en/articles/computers/29-time-inversion-pattern
• http://www.robvens.nl/en/articles/computers/28-active-passive-pattern

Answer 5

Ho un parere simile a Pete, il suo più sul design.

Saltare su di esso prima di aver guardato le informazioni di qualità probabilmente non ti darà i risultati. Probabilmente ti farò solo pensare: questi test sembrano un dolore. Questo è un fatto che ci sono problemi di progettazione, ma non ti dirà come migliorarlo.

Hai detto "attualmente in PHP, ma < 100 righe di codice non layout", se questo è il caso, c'è probabilmente una manciata di funzionalità. Se ti concentri sulle funzionalità effettive necessarie, dovrebbero esserci anche alcuni test/superiori alla quantità di caratteristiche, naturalmente, ma fintanto che questi sono i test di unità giusti, il numero non dovrebbe esplodere - check this video.