Hva er Behavior-Driven Development (BDD)?

Question

Accepted Answer

**Behavior-Driven Development (BDD)** er en tilnærming som beskriver programvareatferd i **klart, strukturert språk** (Given-When-Then) som er forståelig for både tekniske og ikke-tekniske personer — og bygger bro i kommunikasjonen mellom utviklere, testere og interessenter i virksomheten, med tester avledet fra disse beskrivelsene.

## Hva BDD er

```text
BDD focuses on describing BEHAVIOR in business-readable language:
  → write SCENARIOS in a structured natural-language format (Gherkin):
    GIVEN some initial context
    WHEN an action/event happens
    THEN an expected outcome occurs
  → these scenarios are both DOCUMENTATION and executable TESTS
→ Bridges devs, QA, and BUSINESS stakeholders with a shared, readable language.
```

## Et Gherkin-scenario

```gherkin
Feature: User login
  Scenario: Successful login
    Given a registered user with valid credentials
    When they submit the login form
    Then they should see their dashboard
    And a welcome message should be displayed
```

```text
→ Tools (Cucumber, SpecFlow, Behave) map these plain-language steps to test code that runs
→ Non-technical stakeholders can READ and even help WRITE scenarios (shared understanding)
```

## BDD vs TDD

```text
TDD → developer-focused; tests drive code design; "is the code correct?" (unit level)
BDD → behavior/business-focused; scenarios describe FEATURES in shared language;
  "does it do what the business wants?" (collaboration, requirements as tests)
→ BDD extends TDD's idea toward COLLABORATION and business-readable specifications.
  (Given-When-Then = Arrange-Act-Assert in business terms.)
```

## Hvorfor det betyr noe

Å forstå Behavior-Driven Development er verdifullt fordi det er en innflytelsesrik tilnærming som **legger vekt på samarbeid og forretningslesbare spesifikasjoner**, så det er nyttig kunnskap for å forstå testing- og kravpraksis.

BDDs kjerneide — å beskrive programvareatferd **i klart, strukturert språk (Given-When-Then)** som både tekniske og ikke-tekniske personer kan forstå — adresserer en reell utfordring: kommunikasjonen mellom utviklere, testere og interessenter i virksomheten om hva programvaren skal gjøre.

Ved å skrive **scenarier i forretningslesbart språk** som fungerer både som **dokumentasjon og kjørbare tester** (via verktøy som Cucumber), skaper BDD en delt forståelse hvor interessenter kan lese og til og med hjelpe til med å skrive spesifikasjonene, noe som reduserer misforståelser om krav.

Å forstå **Given-When-Then-strukturen** (Gitt en kontekst, Når en handling, Så et utfall — BDDs omformulering av Arrange-Act-Assert) og hvordan verktøy kartlegger disse vanligspråklige stegene til kjørbar testkode er den praktiske kunnskapen.

Å forstå **BDD vs TDD** avklarer deres forhold: TDD er utvikler-fokusert (tester som driver kodedesign, "er koden riktig?"), mens BDD er atferd/forretnings-fokusert (scenarier som beskriver funksjoner i delt språk, "gjør det det som virksomheten ønsker?") — med BDD som utvider TDDs ide mot samarbeid og forretningslesbare spesifikasjoner.

Å forstå BDD reflekterer bevissthet om praksis som forbinder testing med krav og interessentkommunikasjon.

Selvom ikke alle team bruker BDD formelt, er konseptene (atferd-fokuserte scenarier, samarbeid, kjørbare spesifikasjoner) innflytelsesrike og verdt å forstå.

Ettersom BDD er en innflytelsesrik tilnærming som legger vekt på samarbeid og forretningslesbare atferdsspesifikasjoner (bygger bro i teknisk og forretningskommunikasjon, med kjørbare scenarier), og ettersom å forstå den og dens forhold til TDD reflekterer testing- og kravmodenhet, er det verdifullt, relevant kunnskap å forstå Behavior-Driven Development — en bemerkelsesverdig tilnærming som forbinder testing med samarbeid og krav, nyttig for å forstå hvordan team kan justere tekniske tester med forretningslesbare spesifikasjoner og interessentkommunikasjon.