Ruby  »  Articoli  »  Rails 

Quando sviluppiamo un'applicazione (Web o meno) dobbiamo dedicare del tempo a testarne le funzionalità. Esistono decine di tecniche di test diverse, cosi come decine di possibili implementazioni.

Tra queste spicca il Behavior Testing; questa tecnica fa parte di un più corposo stile di programmazione chiamato BDD, o Behavior Driver Development, che cerca di focalizzare l'attenzione dello sviluppatore sugli aspetti di un'applicazione creando in questo modo un flusso di lavoro orientato all'analisi delle macro-caratteristiche funzionali più importanti.

Ad esempio supponiamo di dover sviluppare un'applicazione per la gestione di un autosalone, in particolare stiamo creando la parte per la ricezione delle automobili ordinate dai clienti. In un contesto BDD ecco in che modo porre le specifiche per tale azione:

Scenario: Ricezione di un automobile

Dato un fornitore 
e la presenza in magazzino di tre automobili
Quando il fornitore consegni un automobile
e l'automobile sia priva di difetti
e l'automobile sia del modello richiesto
Allora in magazzino saranno presenti quattro automobili
e al fornitore verrà certificata l'avvenuta consegna

Quanto ho appena scritto viene chiamato in gergo un 'exemplar' e serve ad illustrare il comportamento atteso dal programma a fronte di uno scenario stabilito. Gli Exemplar sono molto comodi in quanto fanno emergere alcuni dettagli di implementazione che altrimenti resterebbero nascosti all'interno di descrizioni troppo generali.

RSpec Stories utilizza gli exemplar come veicolo di testing, come scopriremo più avanti, questa libreria dà la possibilità di associare ad ogni espressione (sentence) un blocco di codice e di utilizzare alcune parole chiave all'interno del testo (Given, When, Then) per stabilire le varie fasi del test (setup, azioni, assunti). Prima di entrare nel dettaglio di quanto appena introdotto vorrei però spendere un capitolo in una veloce introduzione a RSpec in modo da completare questa panoramica sugli strumenti BDD disponibili.

Rspec

David Chelimsky (l'attuale mantainer di RSpec e RSpec Stories) descrive RSpec come: «un DSL, per descrivere il risultato atteso da un particolare sistema utilizzando dati di esempio». Nella pratica RSpec fornisce alcuni metodi molto intelligenti (should, shouldn't, ...) per generare unit test ad alto contenuto semantico, come ad esempio:

@credit_card.should be_valid

In questo caso il contenuto del test è assolutamente percepibile anche a livello semantico (la carta di credito deve essere valida) pur essendo stato scritto in linguaggio Ruby. Questo risultato è possibile grazie al metodo should che viene aggiunto a run-time all'interno della classe Object divenendo quindi accessibile da tutte le istanze dell'applicazione.

Altri articoli

Altre guide

Altre newsletter