The workshop was very well attended, and so I’ve posted a Norwegian language summary on the company blog for Steria Norway. Go check it out if you understand Norwegian!

Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort!

Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

• Meld deg på som deltager eller foredragsholder
• Meld deg på LinkedIn-gruppa vår
• Meld deg på mailingslista for de som er interessert i Smidig 2010

Dersom du vil prøve deg på samme øvelse, inneholder denne artikkelen litt informasjon for å komme i gang. Start med koden under og følg feilmeldingene. Send en kommentar dersom du ikke kommer videre fra en feilmelding, så får vi en FAQ.

Oppgaven

Løs et så enkelt som mulig problem som involverer websider og database med så enkel teknologi om mulig.

Oppgaven jeg har laget går ut på å opprette personer med fullt navn og søke etter personer basert på navnet deres. For å gjøre oppgaven så lite som mulig har jeg valgt å la personer kun ha ett informasjonsfelt: Fullt navn. Denne oppgaven tar cirka 2-3 timer uten øvelse og du kan få den ned i 60-90 minutter med trening.

Du kan naturligvis velge en annen oppgave, men uansett hva du velger: Det er mer lærerikt å gjenta den samme oppgaven flere ganger enn å utføre en avansert oppgave.

Når jeg utfører oppgaven er det viktigste jeg lærer meg å forstå feilmeldingene som guider meg gjennom utviklingen. Dersom du trenger hjelp til å komme til de første feilmeldingene kan du se resten av artikkelen.

Steg for steg: Startpunktet

Selv om jeg valgte veldig enkel teknologi for implementasjonen, har jeg valgt et større sett med biblioteker for å skrive testene. Jeg bruker følgende når jeg skriver testene:

• JUnit 4.6
• Jetty 6.1.22
• HSqlDb 1.8.0.10
• WebDriver-HtmlUnit 0.6.1039
• Mockito 1.8.0
• FEST-assert 1.2 (ikke påkrevd, men gjør testene søtere)

Den eneste teknologien jeg har valgt for implementasjonen er Servlet-API 2.5 og Hibernate-Annotations 3.4.0.GA.

For at du skal slippe å plundre så mye med avhengigheter før du kommer i gang har jeg laget en pom.xml-fil som du kan ta utgangspunkt i.

Web-tester

For å starte utviklingen, er det lurt med en test som starter på utsiden av applikasjonen. Noe slikt:

1. Start opp miljøet
2. Legg inn en person
3. Søk etter personen

Slik kommer du i gang med en test som går mot en web applikasjon:

int SERVER_PICKS_PORT = 0;
org.mortbay.jetty.Server server = 
       new org.mortbay.jetty.Server(SERVER_PICKS_PORT);
server.addHandler(
       new org.mortbay.jetty.webapp.WebAppContext("src/main/webapp", "/"));
server.start();
 
int serverPort = server.getConnectors()[0].getLocalPort();
 
org.openqa.selenium.WebDriver browser =
       new org.openqa.selenium.htmlunit.HtmlUnitDriver();
browser.get("http://localhost:" + serverPort + "/");
browser.findElement(By.linkText("Create person"));

Dette oppsettet forventer å finne web.xml-fila på src/main/webapp/WEB-INF/web.xml.

Funksjonell test

En funksjonell test definerer kravene i applikasjonen. Det er lurt å gjøre funksjonelle tester så raske som overhode mulig, samtidig som de går gjennom alle kravene. En funksjonell test trenger ikke være en ende-til-ende test, slik som eksempelet over. Dette er viktig, fordi ende-til-ende tester er ofte veldig trege. Her er noen eksempler på funksjonelle tester:

• Vis en siden for å opprette nye personer
• Opprett en ny person
• Verifiser at personens navn er oppgitt og ikke inneholder ulovlige tegn
• Vis en side for å søke etter personer
• Vis alle personer dersom søkestreng ikke er angitt
• Søk etter angitt søkestreng

En funksjonell test kan se slik ut:

PersonServlet servlet = new PersonServlet();
 
HttpServletRequest req =
    org.mockito.Mockito.mock(HttpServletRequest.class);
HttpServletResponse resp =
    org.mockito.Mockito.mock(HttpServletResponse.class);
 
PersonDao personDao =
    org.mockito.Mockito.mock(PersonDao.class);
servlet.setPersonDao(personDao);
 
org.mockito.Mockito.when(req.getMethod())
    .thenReturn("POST");
org.mockito.Mockito.when(req.getPathInfo())
    .thenReturn("/create.html");
org.mockito.Mockito.when(req.getParameter("full_name"))
    .thenReturn("Johannes Brodwall");
 
StringWriter pageSource = new StringWriter();
org.mockito.Mockito.when(resp.getWriter())
    .thenReturn(new PrintWriter(pageSource));
 
servlet.service(req, resp);
 
org.mockito.Mockito.verify(personDao)
    .create(Person.byName("Johannes Brodwall"));
 
org.fest.assertions.Assertions.assertThat(pageSource.toString())
    .contains("Personen er opprettet");

Data-aksess-test

Hibernate forenkler databasebruken mye. Men Hibernate er selv komplekst og når man bruker det på mer avanserte måter fortjener det egne tester. En typisk test med Hibernate kan være:

1. Legg i tre personer i database
2. Søk etter en del av navnet på en av dem
3. Sjekk at du får tilbake akkurat den du forventet

Når jeg starter med Hibernate, lager jeg en test som dette, og følger feilmeldingene. Pass på å både følge feilmeldinger i loggen og stack tracer.

AnnotationConfiguration conf = new AnnotationConfiguration()
    .setProperty(Environment.URL, "jdbc:hsqldb:mem:persondaotest");
PersonDao dao = new HibernatePersonDao(conf.buildSessionFactory());
 
dao.create(Person.withName("foo"));
 
org.fest.assertions.Assertions.assertThat(dao.find(null))
    .containsExactly(Person.withName("foo"));

Følg feilmeldingene herfra.

Integrasjon

En veldig vanlig måte for web serveren å overlevere spesielt ting som DataSources til applikasjonen er via JNDI. I Jetty kan du gjøre dette i Web-testen på følgende måte:

org.hsqldb.jdbc.jdbcDataSource ds = new org.hsqldb.jdbc.jdbcDataSource();
ds.setDatabase("jdbc:hsqldb:mem:personwebtest");
ds.setUser("sa");
new org.mortbay.jetty.plus.naming.Resource("jdbc/primaryDs", ds);
 
// Oppstart av Jetty som vist over

Konklusjon

Å gjøre en liten øvelse som dette er en god måte å bli bevisst hvilke vaner du har og hvor lang tid det egentlig tar for deg å gjøre oppgavene dine. Du vil oppleve at det å skrive tester før koden føles som om det går saktere enn du tror du er vant til.

Men dersom du er som meg, vil du også oppleve noe annet: Når du tester ut applikasjonen første gang (du kan gjøre dette med Jetty, naturligvis) så er sjansene gode for at den vil være nokså feilfri og at debugging i stor grad er overflødig. Jeg vet ikke med deg, men debugging er en aktivitet jeg gjerne blir kvitt.

1. Ha en organisert struktur med at man gjennomfører navngitte migreringer (a la Ruby-on-Rails sine migrations eller dbdeploy). Typisk er det vanlig og velfungerende å navngi scripts med løpenummer (001, 002, …) eller timestamp (20091124071300, …) og ha en tabell i databasen som holder styr på hva som har blitt kjørt
2. Bruk views og materialiserte views for å støtte tilbakekompabilitet (NB: Oracle er veldig sterk på dette, andre databaser kan slite)
3. Om mulig, gjør hver migrering bakoverkompatibel på en versjon av programvaren. Dette er lettere å få til jo hyppigere du releaser programvaren
4. Skill endringer i skjema (for eksempel: legg på en kolonne) fra migrering av data (for eksempel: populere kolonnen). Feilene vil typisk ligge i #2 av disse, og den er lett å gjøre transaksjonell, mens skjemaendringer ikke er transaksjonelle i de fleste baser.

Har jeg dekket det viktigste da?

This Norwegian language article introduces a short two-page guide I’ve written to explain Scrum to people who’ve only just heard of it.

I samarbeid med våre dyktige redaksjonelle medarbeidere på Steria, har jeg forfattet en “3 minutters guide” til Scrum. Denne tar for seg spørsmålene som “hva er egentlig Scrum”.

Dette er Scrum

3-minutterguidene kan lastes ned fra Sterias hjemmesider.

Jeg planlegger å følge opp denne guiden med en guide som beskriver hva som skal til for å faktisk lykkes med Scrum. Har du noen ideer?

This Norwegian language post talks a little about a quick intro to Scrum that I wrote for my employer

Jeg har forfattet en “3-minutters guide” til Scrum. Dette er en to siders lettlest artikkel som publiserer via min arbeidsgiver Steria. Denne har som mål å være tilgjengelig både for tekniske og ikke-tekniske prosjektdeltagere som gjerne vil forstå litt mer om hva Scrum dreier seg om.

Du finner artikkelen på Sterias arkiv over 3-minuttersguider. Du kan ta kontakt dersom du ønsker et eller flere eksemplarer av guiden trykket på solid papir.

Jeg regner med å lage flere iterasjoner av denne guiden, så tips om forbedringer mottas med takk.

This is a Norwegian language copy of an article I published with Niklas Bjørnerstedt in the Norwegian computing magazine ComputerWorld

Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre” flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling. Vi synes dette er en hederverdig innsats som vi har lært mye av. Vi synes dog at Magne har blitt overivrig i det siste. I både artikler og foredrag virker han å fremfekte et syn som stiller spørsmålstegn ved all erfaring som ikke er vitenskapelig bevist. Det siste eksemplet på dette synet sto å lese i CW den 24. mars. Når artikkelen bruker denne skepsisen til å koble smidig utvikling med ord som “mote” og “tro” så føler vi at forskeren er i ferd med å kaste ut barnet med badevannet.

Kan det noen gang bevises at smidig utvikling er effektivere enn “tradisjonell utvikling”? Problemstillingen er sannsynligvis for åpen. Det finnes mange måter man kan definere “effektiv” på, en uendelig antall måter å være smidig på og enda flere måter å utvikle på som ikke er smidige. Vitenskapelige studier må redusere en problemstilling til noe som lar seg måle. For eksempel: Gir parprogrammering færre defekter enn individuell programmering? Faren med å redusere problemstillinger på denne måten er at det som gjenstår kan bli et meningsløst spørsmål uten kontekst. Et studie har for eksempel nylig vist at en naken mann (eller kvinne) ikke mister mer varme gjennom hodet enn resten av kroppen. Men dette er ikke relevant til hvor vidt vi bør ta på oss lue om vinteren: I det virkelige livet er det få som velger å gå ut nakne på vinteren, men mange som går barhodet. I sitt foredrag på Software 2009 hevdet Magne tilsvarende at Fred Brooks berømte påstand “Adding manpower to a late software project makes it later” ikke er verdt mye da det er en overforenkling (Brooks skal selv ha innrømmet at det er en “outrageous oversimplification”). De fleste prosjektledere vil derimot si at dette er et godt eksempel på en erfaringsbasert regel. Selvfølgelig er den ikke sann i alle tilfeller, men man bør ha gode grunner for å bryte den.

Som et komplement til vitenskapelige studier er det jo vanlig å bruke erfaringsbaserte slutninger. Disse erfaringene kan være falske, vi mennesker er mestere på å lure oss selv, men det må likevel være bedre å basere seg på en erfaring enn å bare gjette. Hvis det så kommer vitenskapelige studier som tilsier at erfaringen er falsk så er det et grunnlag for å endre adferd. Det er viktig å samle erfaring på en måte som er tilnærmet vitenskapelig for å unngå noen av de fallgruvene Magne gir eksempler på i sine innlegg.

Systematisk bruk av erfaringer er også fundamentet for smidige metoder. Etter en kort iterasjon revurderer teamet resultatet og sin arbeidsform. Målet er nettopp å basere seg på erfaring og empiri framfor blind tro. Slik vil et smidig team bruke iterasjonene på å hente inn mer informasjon om teknikkene de bruker, måten de jobber på og hvor vidt arbeidet deres tilfredsstiller kundens behov.

Smidige metoder er heller ikke en moteting, slik Magne ser ut til å hevde. Smidig utvikling har en lang tradisjon. Det oppsto ikke med det smidige manifestet i 2001. Tankeretningen vokste ut fra det samme miljøet som ble kalt objektorientert på 90-tallet. Dette er et miljø med sterke bånd til akademia tilbake fra Smalltalk og Simula67 før dette. I tillegg har man lånt fra Toyota Production System sin erfaring innen prosessindustrien. En tradisjon som bygger på det W. Edwards Deming kalte Plan-Do-Check-Act – en tilpasning av den vitenskapelige metode til industrien.

Smidig utvikling er et rammeverk for å lære fra erfaring. På samme måte som man kan bruke vitenskapens verktøy bra eller dårlig, kan man bruke smidig utvikling bra eller dårlig. Det vil aldri finnes metoder som garanterer at vi lykkes. I stedet ønsker vi metoder som hjelper oss å oppdage når vi ikke gjør det.

Niklas Bjørnerstedt, Leanway
Johannes Brodwall, Steria

Publisert i Computerworld 22. mai 2009 (kun i papirutgaven)

This blogpost is a Norwegian language tribute to one of my home city’s great poets

Med takk til Joachim Nielsen

Ta en titt inn på skjermen din æ’kke testen grønn
Det var mye værre her om da’n da var alle tester røde
Skulle vært her i forrige uke, da hadde byggserver’n stopp
Alt jeg tenker på er test og kode og bygg og mat hver bidige dag

Alt kan refaktoreres, alt kan leveres
Alt kan refaktoreres, og ingen ting blir bedre

Jeg våkner i den samme gamle klassen og håper på det beste
Tomme tester og tommere metoder, her er gutten som kan refaktorere
Alle koderne som var her i går har forsvinni til no’ bedre
Hver dag er den samme som den neste, ut og refaktorere

Alt kan refaktoreres, ingen ting kan heles
Alt kan refaktoreres, og ingen ting blir bedre

Jeg sitter her og tester igjen, min oppfinnsomhet har grenser
Skulle hatt no’ design eller no’ krav, eller begge deler
Alle folka går å prater om meg her skal det konverseres
Dem begynner å bli skikkelig lei, her må det kritiseres

Ta en titt på skjermen din, æ’kke testen grønn (ikke vær så kjedelig)
Det var mye værre her om da’n da var alle tester røde (ikke reproduserbar)
Skulle vært her i forrige uke, da hadde byggserver’n stopp (kan det være mulig)
Alt jeg tenker på er test og kode og bygg og mat hver bidige dag

Alt kan refaktoreres, alt kan leveres
Alt kan refaktoreres, og ingen ting blir bedre

Jeg våkner i den samme gamle klassen og håper på det beste
Tomme tester og tommere metoder, her er gutten som kan refaktorere
Alle koderne som var her i går har forsvinni til no’ bedre
Hver dag er den samme som den neste, ut og refaktorere

Alt kan refaktoreres
Alt kan leveres
Alt kan refaktoreres
Og ingen ting blir bedre

Alt kan refaktoreres
Alt kan leveres
Alt kan kopieres
Og ingen ting blir bedre

Alt kan refaktoreres
Alt kan refaktoreres
Alt kan refaktoreres
Alt kan refaktoreres

Forslag til refaktorering av sangen mottas med takk