Ho sempre sviluppato mettendo su carta quello che mi serviva per
l’applicazione e poi scrivendo il codice necessario.
Niente test driven e simili.
Ho visto un video su cucumber in rete e mi e’ sembrato uno strumento
utile per lo sviluppo cosi’ ho provato a scrivere la mia prima feature
e il mio primo scenario:
Feature: See Pcs List
In order to make a filter
As a logged user
I want to see the pcs list
Scenario: Pcs List
Given I am logged in
When I go to the home page
Then I want see the pcs list
Bene, ho lanciato cucumber e ovviamente ha rilevato delle azioni
pendenti che ho risolto creando il modello user e il modello pc.
Mi sono fermato qui e ho pensato, si ma in definitiva e’ la stessa
cosa che faccio quando metto su carta i requisiti dell’applicazione.
Se so gia’ che ho bisogno di uno User e di un Pc a cosa mi serve
scrivere la feature e lo scenario? Lo trovo pleonastico ma sicuramente
molto ancora non mi e’ chiaro.
Se so gia’ che ho bisogno di uno User e di un Pc a cosa mi serve
scrivere la feature e lo scenario? Lo trovo pleonastico ma sicuramente
molto ancora non mi e’ chiaro.
Il BDD serve non tanto a suggerirti i model di cui hai bisogno ma,
partendo
dalle specifiche, come i tuoi controller dovranno comportarsi.
Tu prima definisci cosa ti attendi dalle tue API, poi sviluppi il codice
fino a quando non rispetta le tue specifiche.
Se lo vedi in un’ottica di lavoro condiviso, il BDD pu essere una
killing
feature. Magari chi scrive gli scenari di Cucumber la persona che ha
parlato col cliente e chi scrive le API uno degli sviluppatori del
backend.
pleonastico e’ una buona definizione per cucumber.
Ci sono molti appassionati, io non lo sono per niente.
Il BDD e’ venuto fuori da Dan N. (*) e altri per chiarificare che non
scriviamo test ma del codice che descrive comportamenti per il codice.
Ne ho usato i concetti (ma con semplici unit tests) e l’ho trovato utile
soprattutto a chiare alcuni concetti di testing con junior developers.
Quello che vedo e’ un sacco di gente che testa troppo e perde un sacco
di tempo a scrivere tests di Cucumber, in teoria l’esperto di dominio
(non lo sviluppatore) dovrebbe arrivare a scrivere tests di cucumber che
poi andrebbero fissati dal team implementando nuove funzionalita’.
E’ un po’ un’utopia ma ho sentito che in alcuni team funziona.
A parte l’utopia sono dell’idea che il team debba diventare esperto del
dominio, scrivere qualche test quando necessario e buona notte.
rspec e’ molto carino e IMHO alla fine della fiera basta e avanza
premesso che ho iniziato ad usare Cucumber da poco, per quanto mi
riguarda mi trovo meglio
Cucumber non serve solo ad annotarsi i requisiti dell’applicazione,
almeno parlando di Rails, uno dei procedimenti usati questo:
scrivere gli scenari in Cucumber, da un lato funziona come annotazione
di specifiche (allo stesso modo che scriversele su un pezzo di carta),
dall’altro aiuta a verificare la visione di insieme su tutta
l’applicazione, e magari anche a controllare l’output html/js. questo
aspetto sulla carta non p
si scrivono i test per i controller (functional tests), per verificare
che le richieste/risposte si comportino come previsto
infine i modelli (unit tests), per verificare che anche le operazioni
relative al database (letture, scritture, validazioni, etc…) siano
corrette
come vedi, ciascuna tipologia di test controlla il corretto
funzionamento di determinati aspetti dell’applicazione. se sono ben
impostati, si evita anche il rischio di ridondanza
questo thread su stackoverflow potrebbe toglierti qualche dubbio:
non saprei, di norma cerco direttamente in inglese per non perdere tempo (e poi in Italia sono relativamente pochi quelli che usano ruby,
figuriamoci cucumber :P)
(e poi in Italia sono relativamente pochi quelli che usano ruby,