(Behaviour Driven Development är förlänging av Test Driven Development. Det viktigaste man mest justerat är att språket är rätt. Dels ska testerna formuleras på ett naturligt språk som är begripligt för alla stakeholders, även icke-programmerare. Dessutom försöker man inom BDD undvika att prata om testerna som ”tester” eftersom det inte är testerna i sig dom är det viktiga, utan beteende, hur systemet beter sig. Alltså behaviour driven i stället för test driven.)

David Evans pratade under en av de sista presentationerna om hur man får ut så mycket som möjligt av sina BDD artefakter.
Artefakter är helt enkelt de ”tester” man har som skapat. Anledningen till att han krånglar till det och inte kallar dem för tester är att de är mer än bara tester:

• Innan utvecklingen börjar har artefakten ett värde som specifikation,
• under utvecklingen fungerar den som test och
• efter att en feature är färdigutvecklad fungerar artefakten som dokumentation

Som en <stakeholder>

vill jag <funktion>

för att <affärsnytta>

För att uppnå <affärsnytta>

som <stakeholder>

vill jag <funktion>

Givet <tillstånd innan>

När <något som sker>

Så ska <resultat>

En inspirerande keynote av Jeff Atwood, en av grundarna till den fantastiska StackOverflow.com, fick mig att tänka kring gamification. Stackoverflow använder gamification i stor utsträckning. Tanken är att användandet av siten är som att spela ett slags spel och spelar man spelet bra får man utmärkelser. I fallet SO är det helt enkelt så att om man på olika sätt bidrar positivt  (svarar på frågor, uppmärksammar moderatorer på opassande kommentarer etc., så får man utmärkelser, ”badges”, som återspeglar karaktären av ens beteende. T ex kan någon som är väldigt bra på att hålla efter opassande kommentarer få en badge ”ranger”.

Det tjusiga med detta är att det blir roligare för användare att använda tjänsten, användare blir mer motiverade att använda tjänsten på ett ”positivt” sätt och användare blir mer lojala till tjänsten. Om man framgångsrikt har byggt upp en status, har fått åtråvärda badges, så uppstår ett motstånd till att sluta använda tjänsten.

I mina ögon är detta en klassisk win-win. Bra både för den som använder och den som driver tjänsten. Vi driver tjänster där vissa är klockkerna att införa gamification på. Let´s do it.

Det grymma med att vara på en bred utvecklarkonferens som Øredev är ju att det är lätt att gå lite utanför den vanliga fåran, där man brukar vara.

Jag har gått på några UX presentationer idag som varit rätt bra. Om man ska vara riktigt generös med tolkningen av användare så var jag på en igår också på temat ”API the hidden UI”. Tanken är att den som kommer använda ditt API också är någon form av användare, en stor skillnad är dock att ett GUI kan ändras efter att det börjat användas, ett API kan däremot inte ändras utan att saker verkligen går sönder för användare. I princip kan man säga (ok, lite hårddraget) att man bara har en chans att göra API:t rätt. När det publicerats är det användarna som äger det. Inte själva implementationen, men du kan inte ändra hur som helst längre.

Flera av lärdomarna där har jag hört upprepas idag på mer traditionella UX presentationer t ex:

• När man får förfrågningar om nya funktioner får man det oftast i form av ett halvfärdigt lösningsförslag. Försök att fokusera på det underliggande problemet istället. En princip som kan användas är att det inte ska bli bättre bara för en användare utan för många. Beställaren ska kunna motivera varför, för vilka den löser vilket problem.
• Använd konventioner som är utbredda. Analogt med att användare spenderar mest tid på andra webbplatser än din egen, så spenderar API-användare mest tid med andra API:er än ditt. Ett exempel är att en relation mellan brukar benämnas parent-child. Om man i sitt API kallar det för father kommer det bli förvirrande.

Jeff Patton presenterade två klassiska ”failure modes” när man utvecklar och jobbar (mindre bra) med UX:

1. Man antar att ”om jag gillar det så kommer användarna också göra det”
2. Man frågar användare direkt vad de vill ha och ger användare skulden om det inte blir bra.

Under onsdagen var jag på ett par bra dragningar om REST (REpresentational State Transfer) som är det sätt som ”alla” bygger sina API:er på idag. Eller åtminstone påstår att man bygger sina API:er på. Nåväl jag ska inte orera om missuppfattningar om REST.

Vad jag dock kan konstatera är att ett centralt begrepp, som jag knappast sett ”in the wild” är HATEOAS (Hypermedia As The Engine Of Application State). Jim Webber förklarar dock föredömligt pedagogiskt vad det handlar om. Utgående från det självklara i hur vi som människor genom vår browser navigerar genom ett checkout-flöde på typ amazon. När vi börjar vår utcheckning gör vi det genom att följa en hyperlänk. Vi vet i det läget inte vart vi senare kommer navigera, men vi får hjälp från applikationen genom att vi förses med länkar genom t ex anchor-taggar eller form targets som för oss människor (förhoppningsvis) har en uppenbar semantik. Typ vi ser våra varor och när vi klickar på knappen ”betala” förväntar vi oss att komma till en sida där vi… betalar. Inget konstigt – HATEOAS. Samma tankesätt kan generaliseras till att även omfatta maskin-till-maskin kommunikation, där dock länkarnas semantiska innebörd måste formaliseras.

En annan sak som Jim Webber uppenbarligen brinner för är att omfamna HTTP som det applikationsprotokoll det faktiskt är. Mer specifikt ett applikationsprotokoll inom domänen att skyffla runt dokument på internet.

Det vi gör när vi då navigerar mellan dessa resurser som pekas ut av länkar är att vi skickar och tar emot dokument. Allt som verkligen händer med våra domänobjekt är sidoeffekter av att dokumenten skyfflas runt. Det behöver INTE råda en ett-till-ett relation mellan resurser och domänobjekt!

Ian Robinson pratar senare om Test-Driven Rest. Inte helt förvånande använder han i mycket samma analogier som Jim Webber (de har skrivit boken Rest in Practice tillsammans).

Ian har dock en kort lista på saker som kan vara bra att testa isolerat när man testar sitt REST API:

• Att HTTP interaktionen går som den ska. Att man får rätt responskoder och headers etc.

• Att interaktionen med underliggande domänrepresentationer sker som den ska.
• Att rätt responser ges på rätt format.
• Och att hypermedia dyker upp som det ska, ledtrådar till vad som kan göras härnäst.