Integrazione vs test di accettazione ... che cosa è cetriolo / Steak?

Question

Per i test di integrazione del mio Rails web app che uso Steak (qualcosa come cetriolo). Le specifiche di bistecca sono in una cartella denominata spec / accettazione. Sono Steak / Cetriolo ora integrazione o test di accettazione? Ho sempre pensato che questo è qualcosa di diverso.

Answer 1

In primo luogo, una nota sulla terminologia: test di integrazione il termine è un po 'vaga nella comunità TDD. A seconda se si proviene da Java o Rails (con Test :: Unit), si potrebbe capire le cose diverse da esso. In Rails (con Test :: Unit) test di integrazione sono i test che mettono alla prova il vostro stack completo, mentre i test funzionali sarebbero quelli test controller. La maggior parte delle persone nella comunità Java (almeno da parte mia osservazione) avrebbero pensano che sia il contrario. Io personalmente preferisco chiamare i test end-to-end prove di collaudo , mentre i test che hanno colpito diversi strati del sistema (ma non tutto) - test di integrazione . Tutto sommato, che è abbastanza dipendente dalla cultura vostro sono in.

Per quanto riguarda cetriolo e bistecca - entrambi sono strutture che consentono uno stile di sviluppo conosciuto come behavior-driven development (o BDD in breve). Il punto è che si hanno due livelli di test:

• end-to-end test , che prova la vostra attraverso lo stack completo - simulano un browser, passare attraverso i controller e ha colpito il database. Cetriolo e Steak adattano questa nicchia.
• test unitari , che prova una piccola porzione di funzionalità isolatamente (di solito una singola classe, scherno suoi collaboratori). È qui che si inserisce RSpec.

In BDD, si inizia con una mancanza di test end-to-end (amorevolmente conosciuta come la "marcia superiore"), e poi iniziare ad attuare la funzionalità di test-primo con RSpec (la "marcia inferiore"), fino ad arrivare il test di passaggio end-to-end. In questo modo il test end-to-end sta guidando il test di unità, che a loro volta guidano l'implementazione. Il vantaggio principale è di evitare scope creep -. Non si finiscono per implementare la funzionalità user-visibile che non è necessario (in quanto non si scrive un test end-to-end per esso)

Se volete maggiori informazioni su questo, ho sentito che il Behavior Driven Development articolo Wikipedia è sorprendentemente buono. Inoltre, il libro RSpec.

Quindi, sia Cetriolo e bistecca sono strutture che permettono di scrivere i test nella "marcia superiore". La differenza è in stile - Cetriolo vi ha scrivere i test in linguaggio naturale. Questo ha diversi vantaggi.

• I test sono leggibili dagli uomini d'affari - anche se non ci si può aspettare i non-programmatori di scrivere loro, fanno un ottimo lavoro nel comunicare ciò che si intende fare. È possibile scrivere la funzione (il test di cetriolo prima) e mostrarlo al cliente di ottenere un feedback su se questo è ciò che effettivamente vogliono. Ho trovato questo molto utile.
• caratteristiche cetriolo comunicare l'intento migliore - dal momento che si arriva a utilizzare tutta la potenza della lingua inglese (o qualsiasi, in realtà), è possibile comunicare perché Questa funzione è pertinenti e come gli utenti compiono il loro obiettivo su un livello che Ruby non permetterà di.
• Cetriolo aiuta a scoprire il linguaggio onnipresente - il dominio comprende un sacco di termini che volano in giro per le conversazioni con i clienti. Cetriolo permette di scoprire e catturare prima di iniziare l'attuazione della funzione. Ed è tutto test-driven.
• caratteristiche cetriolo sono leggermente superiori a livello , che rende le funzioni (ma non le definizioni passo) più indipendenti dell'interfaccia. In questo modo se le esigenze di interfaccia cambia, non sarà necessario rielaborare le caratteristiche.

Gli aspetti negativi sono che è un po 'difficile da imparare come applicarla bene e che si deve scrivere un po' di più (entrambe le caratteristiche e definizioni step). Ho scoperto che la seconda non è davvero un problema se avete fatto per un po ', dato che si ottiene un corpo di passi riutilizzabili che permettono di scrivere le caratteristiche prossimi veloce.

Steak, d'altra parte è più semplice ed è Ruby. Si perde tutto il benefits di usare l'inglese, ma è possibile scrivere di meno e si eseguiranno più veloce (un po ').

In linea di fondo, si utilizza sia di scrivere i test end-to-end che lo sviluppo di auto.