Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
Gi meg et eksempel! Introduksjon til BDD
- 2. Hva er BDD?
- 3. “Kan du gi meg et eksempel?”
- 4. Hvordan ser et eksempel ut? “Gitt at Bergen kommune har laget en forsendelse til Eirik Olsen Og Eirik Olsen sitt fødselsnummer blir oppgitt Når Bergen kommune sender forsendelsen Så burde Eirik Olsen få beskjed om forsendelsen fra Altinn”
- 6. Når skal vi bruke BDD? 1. Alle kan det 2. Noen i teamet kan det 3. Noen i organisasjonen har gjort det før 4. Noen, men ingen vi kjenner, har gjort det før 5. Ingen har gjort det før
- 7. Hvordan bruker vi BDD? 0 Analysere hva løsningen skal gjøre 0 Lage tester og utvikle løsningen
- 8. Hva skal vi lage m/ 3 amigos
- 9. Cucumber
Editor's Notes
- BDD handler om å drive frem utvikling ved å fokusere på oppførsel. Analyseverktøy som hjelper oss å finne ut hva vi skal lage Gir dokumentasjon: hvordan oppfører systemet seg? Gir tester: oppfører systemet seg riktig? Hvis du skal bare lære én ting, følgende setning:
- Basis for å jobbe med BDD (og ATDD, specification by example osv) Dette, og et par spørsmål til gjør deg mulig å lage eksempler som kan skrives som tester.
- Eksempel er tekst (lese eksempel) Viktig: Ingen knapper. Ingen tabeller. Ingen statuser. Vanlig språk. Så enkelt som mulig, så naturlig som mulig. Dette er kjørbar kode btw. Se mer på dette senere. Hvorfor skal vi bruke BDD?
- Felles forståelse for det vi prøver å løse: eksempler er spesifikke. Færre misforståelser: alle kan forholde seg til enkle eksempler Oppførsel i fokus og er tilgjengelig i klartekst Verifikasjon: systemet virker som det skal Drive utvikling basert på oppførsel (utenfra inn-tenkning) Utfordrende å lage gode eksempler, gode språkkunnskaper viktig. (mer om dette senere) BDD egner seg ikke i en hvilken som helst situasjon.
- Oversikt over kompleksitet på oppgaver som skal løses. 1: innlysende, 5: ukjent, komplekst, kanskje mot kaotisk landskap. 3 og 4 er BDD-land. Ikke bruke til trivielle ting, ikke bruke for utforskning eller når utfallet er usikkert. Jo høyere tall, jo høyere risiko. Jobb for å få 5-ere ned mot 4 og 3, så kan BDD brukes.
- To separate deler: Analyse dreier seg om å ha samtaler for å finne ut hva vi skal lage. Tre roller som må være med på disse samtalene/workshopene: utvikler (teknisk kompetanse) tester (kan finne alle varianter og oppdage alle tingene de andre rollene ikke får med seg) domeneekspert fra forretningssiden (kan domenet og har riktig språk) Mål: få oversikt over hvilke evner (capabilities/features) et system skal ha prioritere røff rekkefølge på evner: velge én etablere regler for evne finne eksempler som viser reglene Ender opp med:
- Hvor mange regler har en evne? Mindre enn ti, helst 3-5. Eksempler kan dekke en regel fullstendig, flere regler. Kanskje en regel må ha flere eksempler. Dukker det opp usikkerhet eller konflikter? Lag spørsmål som forretningssiden kan avgjøre. Eksempler er tester. Denne type workshop: samme kategori som specification workshops. Ha workshop så nærmt utvikling som mulig. Fra workshop: helst direkte på utvikling.
- Finnes ulike rammeverk, jeg har brukt Cucumber. Feature: evne, tilsvarer grønne lappen. En featurefil inneholder alle eksemplene, som kalles scenario i Cucumber. Et ark ~= en featurefil Neste lag: knytte scenario opp mot API/domene: steg-definisjoner. Her settes alle tekniske detaljer opp, mapping mellom eksempel i klartekst og faktisk implementasjon. Step-defs kaller din kode. To eksempler avh. av tid: SvarUt: integrasjonstype tester i Java shouty: ruby: oppgave fra kurset jeg var på