Test di integrazione vs accettazione ... che cos'è Cetriolo/Bistecca?

Question

Per i test di integrazione della mia app web Rails uso Steak (qualcosa come Cetriolo). Le specifiche di bistecca sono in una cartella denominata spec/accettazione. Bistecca/Cetriolo sono ora disponibili per l'integrazione o il test di accettazione? Ho sempre pensato che fosse qualcosa di diverso.

Answer 1

In primo luogo, una nota sulla terminologia: il termine test di integrazione è un po 'vago nella comunità TDD. A seconda che tu venga da Java o Rails (con Test :: Unit), potresti capire cose diverse da esso. In Rails (con Test :: Unit) i test di integrazione sono i test che testano lo stack completo, mentre i test funzionali sono quelli che testano il controller. La maggior parte delle persone nella comunità Java (almeno secondo la mia osservazione) penserebbe che sia il contrario. Personalmente preferisco chiamare il test end-to-end test di accettazione, mentre i test che colpiscono diversi livelli del sistema (ma non tutto) - test di integrazione. Tutto sommato, è abbastanza dipendente dalla cultura in cui ti trovi.

Per quanto riguarda Cetriolo e Bistecca - entrambi sono framework che consentono uno stile di sviluppo noto come Sviluppo Comportamentale (o BDD in breve). Il punto è che ci sono due livelli di test:

• end-to-end test, che mettono alla prova la vostra attraverso lo stack completo - simulano un browser, passare attraverso i controller e ha colpito il database. Cetriolo e Bistecca si adattano a questa nicchia.
• Test di unità, che testano un po 'di funzionalità in isolamento (di solito una singola classe, deridendo i suoi collaboratori). È qui che si adatta RSpec.

In BDD, si inizia con una mancanza di test end-to-end (amorevolmente noto come "marcia superiore"), e quindi si inizia implementare funzionalità di test, prima con RSpec (la "marcia inferiore"), fino a quando non si passa il test end-to-end. In questo modo il test end-to-end sta guidando i tuoi test unitari, che a sua volta stanno guidando la tua implementazione. Il vantaggio principale consiste nell'evitare il creep dello scope: non si finisce per implementare funzionalità visibili all'utente di cui non si ha bisogno (dal momento che non si scrive un test end-to-end per esso).

Se desideri maggiori informazioni su questo, ho sentito che lo Behavior Driven Development Wikipedia article è sorprendentemente buono. Inoltre, il libro di RSpec.

Quindi, sia Cetriolo che Bistecca sono strutture che consentono di scrivere test nella "marcia superiore". La differenza è nello stile - Cucumber ti ha scritto i tuoi 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. Puoi scrivere la funzione (il test di Cucumber per prima) e mostrarla al cliente per ottenere un feedback sul fatto che questo sia ciò che realmente vogliono. Ho trovato questo molto utile.
• caratteristiche cetriolo comunicare l'intento meglio - dal momento che si arriva a utilizzare tutta la potenza della lingua inglese (o qualsiasi, in realtà), è possibile comunicare perché questa funzione è rilevante e come gli utenti compiono il loro obiettivo a un livello che Ruby non ti permetterà di
• Il cetriolo aiuta a scoprire il linguaggio ubiquitario - il dominio include molti termini che volano nelle conversazioni con i clienti. Cucumber ti consente di scoprirli e acquisirli prima di iniziare a implementare la funzione. Ed è tutto basato sui test.
• Le funzioni di cetriolo sono in qualche modo di livello superiore, il che rende le funzionalità (ma non le definizioni dei passaggi) più indipendenti dall'interfaccia. In questo modo se l'interfaccia deve essere cambiata, non dovrai rielaborare le funzionalità.

Gli svantaggi includono che è un po 'difficile apprendere come applicarlo correttamente e che è necessario scrivere un po' di più (sia le caratteristiche che le definizioni di passo). Ho scoperto che il secondo non è davvero un problema se lo si fa da un po 'di tempo, dato che si ottiene una serie di passaggi riutilizzabili che consentono di scrivere le prossime funzionalità più velocemente.

Bistecca, d'altra parte è più semplice ed è Ruby. Perdi tutti i benefici dell'uso dell'inglese, ma puoi scrivere meno e verrà eseguito più velocemente (in qualche modo).

Nella riga inferiore, si utilizzano entrambi per scrivere i test end-to-end che guidano lo sviluppo.