I test BDD sono test di accettazione?

StackOverflow https://stackoverflow.com/questions/767439

Domanda

Hai bisogno di qualcosa del genere Fitnesse, se hai BDD test?

È stato utile?

Soluzione

I "test" BDD esistono a diversi livelli di granularità, fino alla visione iniziale del progetto.La maggior parte delle persone conosce gli scenari.Alcune persone lo ricordano BDD ha iniziato con la parola "dovrebbe" in sostituzione del "test" di JUnit - in sostituzione di TDD.Il motivo per cui ho messo "test" tra virgolette è perché BDD non riguarda realmente i test;si concentra sulla ricerca dei luoghi in cui c'è una mancanza o un disallineamento nella comprensione.

Grazie a questo focus, le conversazioni sono molto più importanti degli strumenti BDD.

Lo dirò di nuovo. Le conversazioni sono molto più importanti degli strumenti BDD.

I test di accettazione in realtà non impongono le conversazioni e di solito funzionano partendo dal presupposto che i test che stai scrivendo siano quelli giusti.In BDD presumiamo di non sapere cosa stiamo facendo (e probabilmente non sappiamo di non sapere).Questo è il motivo per cui usiamo cose come "Given, When, Then" - in modo da poter avere conversazioni sugli scenari e/o sugli esempi a livello di unità.(Questi sono i due livelli con cui la maggior parte delle persone ha familiarità - l'equivalente dei test di accettazione e dei test unitari - ma sale sulla scala).

Non li chiamiamo "test di accettazione" perché non puoi chiedere a un uomo d'affari "Per favore aiutami con il mio test di accettazione".Ti guarderanno con uno sguardo davvero strano e strabico e poi ti congederanno come quella ragazza geek.Il 93% di voi non lo vuole.

Prova invece "Vorrei parlarti dello scenario in cui...".Oppure: "Puoi farmi un esempio?" Entrambi sono buoni.Chiamarli "test di accettazione" inizia a far pensare alle persone che stai effettivamente facendo dei test, il che implicherebbe che tu sappia cosa stai facendo e vuoi solo assicurarti di averlo fatto.A quel punto, le conversazioni tendono a concentrarsi sulla rapidità con cui riesci a tirar fuori la cosa sbagliata, invece che sul fatto che stai tirando fuori la cosa sbagliata.

E stai dicendo la cosa sbagliata. Davvero, onestamente, lo sei. Anche se pensi di non esserlo, è solo perché non comprendi l'ignoranza di secondo ordine.Non sai di non sapere, e va bene così, purché tu abbia trovato i posti in cui ti trovi Potevo sai di non sapere.(Non li troverai tutti.Non lasciare che il paradosso della categorizzazione ti tenga sveglio la notte.)

L'unico modo per farlo davvero bene è ottenere Tutto i requisiti in anticipo e sai cosa succede quando lo provi.Giusto.Suo Cascata.Ricordi gli straordinari?Il lavoro del fine settimana?I sette anni in cui nessuna delle cose che hai creato è arrivata alla produzione?Se vuoi evitarlo, hai solo una possibilità:presumi di avere torto, discuti qualche cosa al riguardo per essere meno sbagliato, quindi accetta di avere torto Ancora sbagliato e provaci comunque.Scrivere i test troppo presto significa che hai pareggiato Di più possibilità di sbagliare, e ora è più difficile cambiare e tutti pensano che tu abbia ragione e il Primo Ministro sta misurando la tua velocità e ora ti impegni a sbagliare per altre 2 settimane.E, peggio ancora, stai per verificare che anche tu hai torto.

Di nuovo. Le conversazioni sono molto più importanti degli strumenti BDD.

Per favore, per favore, non fissarti sugli strumenti.Gli strumenti sono solo un meccanismo per catturare le conversazioni e assicurarsi che vengano riprodotte nel codice.Gli scenari non sostituiscono le conversazioni, non più di quanto una scheda 3 x 5 possa sostituire i requisiti.

Detto questo, se tu dovere inizia con uno strumento, metti Slim dietro Fitnesse in modo che possa funzionare bene in Date / When / Thens senza dover interferire con i tavoli e le attrezzature di Fit. GivWenZen è basato su Slim ed entrambi spaccano.FitSharp è l'equivalente per quelli di voi nello spazio .NET.Oppure usa semplicemente Cucumber, o SpecFlow, o procurati una piccola connessione DSL personalizzata* farà bene il suo lavoro per anni.

Trasparenza:*L'ho scritto io.E pezzi di JBehave.Vorrei che lo avessimo chiamato "Non concentrarti sugli strumenti BDD-Comportati bene".Potrei essere fortemente coinvolto in altri aspetti di BDD.In più Dan North mi offrirà una pinta se riesco a diffondere questo messaggio, quindi non è esattamente un consiglio imparziale.

Indipendentemente da ciò, hai già le conversazioni.Sono solo persone.Vai a parlare.

Altri suggerimenti

Non so se c'è una cosa del genere, in senso stretto, come un "test BDD". BDD è una filosofia che suggerisce come si può meglio interagire e collaborare con le parti interessate per completare un progetto complesso. Non fa direttamente eventuali prescrizioni per il modo migliore per scrivere i test. In altre parole, probabilmente avrete ancora tutti i soliti tipi di test (inclusi i test di accettazione) nell'ambito di un progetto BDD-filosofia.

Quando si sente parlare di "quadri" BDD, l'altoparlante di solito significa un quadro per la scrittura di tutti i soliti tipi di test, ma con un tocco BDD. Per esempio, in RSpec, è ancora scrivere unit test; si aggiunge solo il sapore BDD a loro.

Mentre BDD è più grande del campo di applicazione del solo test, ci sono infatti prove di BDD. Questi test sono unit test che seguono il linguaggio BDD.

Dato un contesto iniziale (i dati di fatto), Quando si verifica un evento, poi garantire alcuni risultati.

Ci sono alcuni buoni quadri BDD disponibili a seconda della lingua di preferenza. JBehave per Java RSpec per Ruby NBehave per NET

Mi piace fare una distinzione tra le "caratteristiche" e "test".

Se sto coprendo un metodo chiamato GetAverage(IEnumerable<int> numbers), sto andando a dare una più o meno test di unità standard.

Se sto coprendo un metodo chiamato CalculateSalesTax(decimal amount, State state, Municipality municipality), ancora sto andando a scrivere il test di unità, ma lo chiamerò una specifica perché ho intenzione di cambiare in su (1) per verificare il comportamento della routine, e (2) perché la prova stessa documenterà sia la routine e le sue criteri di accettazione.

Si consideri: 

[TestFixture]
public class When_told_to_calculate_sales_tax_for_a_given_state_and_municipality() // the name defines the context
{
    // set up mocks and expected behaviour
    StateSalesTaxWebService stateService 
        = the_dependency<IStateSalesTaxWebService>;
    MunicipalSurchargesWebService municipalService 
        = the_dependency<IMunicipalSurchargesWebService>;

   stateService.Stub(x => x.GetTaxRate(State.Florida))
        .Return(0.6);
    municipalService.Stub(x => x.GetSurchargeRate(Municipality.OrangeCounty))
        .Return(0.05);

    // run what's being tested
    decimal result = new SalesTaxCalculator().CalculateSalesTax
        (10m, State.Florida, Municipality.OrangeCounty);

    // verify the expected behaviour (these are the specifications)
    [Test]
    public void should_check_the_state_sales_tax_rate()
    {
        stateService.was_told_to(x => x.GetTaxRate(State.Florida)); // extension methods wrap assertions
    }

    [Test]
    public void should_check_the_municipal_surcharge_rate()
    {
        municipalService.was_told_to(x => x.GetSurchargeRate(Municipality.OrangeCounty));
    }

    [Test]
    public void should_return_the_correct_sales_tax_amount()
    {
        result.should_be_equal_to(10.65m);
    }
}

JBehave (e NBehave recentemente aggiunto lo stesso supporto) lavorare con i file di test regolari in modo mentre molti altri framework aggiungere "BDD prove di assaggio tounit" le specifiche di comportamento di testo base / esempi creati con JBehave sono adatti per i test di accettazione. E no, non è necessario fitnesse per questo.

Per avere un'idea di come funziona Suggerisco JBehaves 2min esercitazione .

Per i test BDD in Flex si può provare GivWenZen-Flex controllarlo fuori http://bitbucket.org / Loomis / givwenzen-flex .

Saluti, Kris

test xBehavior BDD attuate ben sono criteri di accettazione dall'utente robo-driven.

test BDD xSpecification sono normalmente unit test ed è improbabile che siano criteri di accettazione utente accettabili.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top