BDD PÅ SKINNER

Hvis du bruker TDD, vil det være enkelt å begynne med BDD - det er i utgangspunktet et sett med beste praksis for det. BDD har et sett med enkle regler som forteller hvordan du skal skrive spesifikasjoner og hva du skal teste. Spesifikasjonene er delt inn i tre deler: Gitt (oppsett av testbetingelser), Når (påkalling av handling på emnet) og Deretter (påstander). Testene bør ha beskrivende navn, og eksisterende testrammeverk gjør det mulig å bruke metoder og assertions som ligner på naturlig språk - alt dette til sammen gir oss tester som er lesbare for både tekniske og ikke-tekniske brukere. Gode navnekonvensjoner er nyttige under regresjonstester.

BDD kommer også med et sett med retningslinjer for testpersoner. I motsetning til TDD flytter BDD fokus fra testing av implementering til testing av atferd - noe som fører til bedre design og gir større fleksibilitet når endringer må innføres. Spesifikasjonene skal være som skriftlige og kjørbare kundekrav - de overordnede skal fungere som akseptansetester. Målet er å skrive tester på en måte som gjør at de bare må endres når kravene endres. Ved å bruke BDD er vi sikre på at vi tester det som virkelig skal dekkes, og det er en mer pragmatisk tilnærming enn TDD.

Hvis du vil se BDD i aksjon, anbefaler vi Ruby. Det er et kraftig språk som er morsomt å bruke, og det har et utmerket BDD-verktøysett.

Agurk

Cucumber er det mest populære rammeverket for BDD i Ruby. Det introduserer et spesielt språk, kalt Gherkin, som du kan skrive testene dine i. I motsetning til RSpec er funksjonene som beskrives i Gherkin ren tekst, ikke kodeog som sådan kan - og bør - forstås av hvem som helst, særlig av kunden.

Cucumber-funksjonen ser slik ut (eksempel hentet fra Cucumber wiki):

 Funksjon: En kortfattet, men beskrivende tekst om hva som ønskes
    En tekstlig beskrivelse av den forretningsmessige verdien av denne funksjonen
    Forretningsregler som styrer omfanget av funksjonen
    Eventuell tilleggsinformasjon som vil gjøre funksjonen lettere å forstå

  Scenario: En bestemt forretningssituasjon
    Gitt noen forhåndsbetingelser
    Og en annen forhåndsbetingelse
    Når en handling utføres av aktøren
    Og en annen handling
    Og enda en annen handling
    Da oppnås et testbart resultat
    Og noe annet vi kan sjekke, skjer også

  Scenario: En annen situasjon
    ...

Funksjonene vil bli beskrevet i detalj senere.

Bruk av agurk i Ruby on Rails

Installasjon

Første skritt for å bruke agurk i din prosjekt er å installere den. Bare legg til disse to gemene i Gemfilen din:

group :test do
  gem 'cucumber-rails', :require => false
  gem 'database_cleaner'
end

Samle dem ved å kjøre pakkeinstallasjonog generere Cucumber-skript og -kataloger med følgende kommando:

rails genererer cucumber:install

Dette vil skape config/cucumber.yml, skript/agurk og funksjoner/ katalog, som vil inneholde .funksjon filer, samt trinndefinisjoner og støttefiler. For å kjøre funksjonene dine bruker du en ny rake-kommando:

rake agurk

Funksjoner

La oss se nærmere på funksjoner. En funksjon er noe applikasjonen din har eller gjør - for eksempel sender den ut nyhetsbrev med jevne mellomrom eller lar brukeren dele bildene sine offentlig. En funksjon består av flere scenarier, som beskriver hvordan denne funksjonen fungerer i ulike sammenhenger.

For å demonstrere grunnleggende bruk av Cucumber i Rails, skal vi skrive en funksjon fra bunnen av. Dette eksempelet vil være den første funksjonen vi skriver i applikasjonen, som vil bli vist i den kommende andre delen av denne artikkelen. Denne applikasjonen vil tillate brukeren å opprette varer og butikker (butikker selger varer) og deretter opprette handlelister.

I den enkleste versjonen, etter å ha satt sammen en handleliste, vil programmet vise i hvilke butikker varene som brukeren ønsker er billigst.

Først oppretter du en ny fil med navnet opprett_element.funksjon i funksjoner/ katalog. Øverst i en .funksjon filen finnes det en Funksjon nøkkelord, etterfulgt av en kort beskrivelse av det. For eksempel

Funksjon: Opprette elementer

I de følgende linjene kan du skrive et forretningsmål som skal implementere denne funksjonen. Siden Cucumber ignorerer tekst som er skrevet før det første scenariet, er det ikke nødvendig å skrive noe, men det er absolutt en god idé.

   For å enkelt lage handlelister med varer som selges i butikker i nærheten
   Som bruker
   Jeg ønsker å legge til varer i systemet

I utdraget ovenfor ser du et ganske populært mønster som du kan bruke for å beskrive forretningsmål. Den består av tre deler: hvorfor er funksjonen nødvendig, hvem vil ha den, og hva er den. Du trenger selvfølgelig ikke å følge dette formatet, men sørg for å inkludere svar på disse tre spørsmålene i beskrivelsen din.

Scenarier

Deretter skriver vi noen scenarier. Hvert scenario begynner med nøkkelordet "Scenario" og inneholder flere trinn.

    Scenario: Opprettelse av unik vare
      Gitt at det finnes en "Melk"-vare
      Når jeg går til hovedsiden
      Og jeg oppretter "Brød"-elementet
      Da ser jeg "Brød" på varelisten 

Så hvis noen har opprettet en vare med navnet Melk, er det mulig å opprette Brød, og det resulterer i at Brød vises på varelisten. Vi bør ikke teste for å opprette en post i databasen, siden dette faktumet ikke har noen reell verdi for kunden.

Scenarios trinn bruker tre hovednøkkelord:

• Gitt, for å tilføre kontekst til scenariet
• Når, for å beskrive handlinger
• Deretter, for å beskrive resultater

Det er viktig å merke seg at Cucumber ignorerer nøkkelordet som trinnet starter med, og bare matcher den siste delen. Dermed kan du starte stegene dine med "And" der det føles naturlig. Den eneste regelen for å velge riktig nøkkelord er at scenariet må være lett å forstå.

Trinndefinisjoner

Når du kjører Cucumber, får du denne utdataen:

[...]
Funksjon: Opprette varer
  For enkelt å kunne opprette handlelister med varer som selges i nærliggende butikker
  Som bruker
  Jeg ønsker å legge til varer i systemet

  Scenario: opprette en unik vare # features/create_item.feature:6
    Gitt at det finnes en "Melk"-vare # features/create_item.feature:7
      Udefinert trinn: "det finnes et "Milk"-element" (Cucumber::Undefined)
[...]

Dette er fordi Cucumber ikke vet hva vi mener når vi sier "det finnes et melkeelement". For å gi stegene dine mening, må du definere dem i trinn_definisjoner katalog.

En anbefalt måte å organisere trinndefinisjonene på er å dele dem inn etter domene. For eksempel tilhører de fleste trinnene vi har opprettet, Item-domenet. Derfor bør vi opprette en fil med navnet step_definitions/item_steps.rb og legg inn følgende kode der:

Gitt "det finnes en "$name"-gjenstand" do |name|
  Fabricate :element, navn: navn
end

Når "Jeg oppretter "$name"-elementet" do |name|
  innenfor "#nytt_element" do
    fill_in "Navn", med: navn
    klikk_på "Opprett"
  end
end

Then "Jeg ser "$name" på varelisten" do |name|
  innenfor ".items" do
    expect(page).to have_content navn
  end
end

Trinndefinisjonene vil vanligvis være basert på Capybara. Hvis du ikke er kjent med Capybara, bør du sjekke ut lenkene på slutten av denne artikkelen.

Det er ett trinn til som må defineres, og det passer egentlig ikke inn i Item-trinnene. Du kan legge det inn i main_page_steps.rb:

Når "Jeg går til hovedsiden" gjør
  besøk root_path
end

Konklusjon

Dette er en veldig enkel historie for en veldig enkel funksjon. Formålet var å demonstrere kjernekonseptene i BDD slik de brukes i Cucumber. Å skrive gode historier krever imidlertid litt mer. Som utvikler må du endre tankesettet ditt fullstendig - glem implementeringen og fokuser på forretningsmålene i stedet. Cucumber gjør denne overgangen enklere med sin smarte bruk av rene teksthistorier.

Kilder, inspirasjon og interessant lesestoff:

• https://github.com/cucumber/cucumber/wiki/Cucumber-Backgrounder
• https://github.com/jnicklas/capybara
• https://blog.engineyard.com/2009/15-expert-tips-for-using-cucumber
• http://blog.codeship.com/cucumber-best-practices/
• http://www.elabs.se/blog/15-you-re-cuking-it-wrong
• https://github.com/strongqa/howitzer/wiki/Cucumber-Best-Practices