Planlegging/forprosjekt:

Vedlegg A Arbeids- og iterasjonsplan Denne arbeidsplanen begynner f.o.m. oppgaven ble bekreftet fra oppdragsgiver, d.v.s. 20. november 2008. Planlegging/forprosjekt: Oppgave Frist Opprette prosjekthjemmeside 5. desember 2008 Prosjektskisse. Skal inneholde kort 5. desember 2008 presentasjon av gruppe, oppdragsgiver og oppgaven. Forprosjekt. Videre presisering av 30. januar 2009 oppgaven, mål, rammebetingelser, forslag til løsninger. Inkluderer arbeids- og fremdriftsplan. (inkluderes i iterasjon 0 og 1) Iterasjon 0 Avsluttes uke 3, 16. januar 2009 Valg av teknologier Sette oss inn i aktuelle teknologier som kan brukes til å løse oppgaven og velge det som vi mener egner seg best. Oppsett av Eclipse, Maven, SVN Verktøy som benyttes i utviklingen Formulere user stories Identifisering av krav og mulig funksjonalitet Sette oss inn i FitNesses oppbygging og praktisk bruk Implementering og testing: Oppgave Iterasjon 1 Som en tester vil jeg ha tilgang til Experior med en link fra menyen i FitNesse Som en tester vil jeg at piper i hele dokumentet skal alignes når jeg åpner det i Experior Frist Avsluttes uke 5, 30. januar 2009 Vedlegg A Arbeids- og iterasjonsplan 1

Iterasjon 2 Som en tester vil jeg ha oversikt over tilgjengelige metodenavn for en DoFixture som angis øverst Iterasjon 3 Som en tester vil jeg ha syntaks-highlighting, d.v.s. at metodenavn har en egen farge Iterasjon 4 Som en tester vil jeg ha syntaks-highlighting, d.v.s. at metodenavn har en egen farge (tatt med fra iterasjon 3) Som en tester vil jeg at hver gang jeg skriver en pipe skal denne alignes etter pipen på forrige linje Som en tester vil jeg kunne lagre testen fra Experior Iterasjon 5 Som en tester vil jeg at hver gang jeg skriver en pipe skal denne alignes etter pipen på forrige linje (tatt med fra iterasjon 4) Som en tester vil jeg at piper i hele dokumentet skal alignes når jeg åpner det i Experior Som en tester vil jeg ha mulighet til å aligne piper korrekt i hele dokumentet ved trykk på en knapp Som en tester vil jeg ha mulighet for å lage overskrifter med ulik størrelse og farge Som en tester vil jeg ha mulighet til å kommentere ut tabeller/tekst og at disse da skal gis egen farge Iterasjon 6 Som en tester vil jeg ha mulighet til både å lagre OG lukke testen, eller bare lagre Som en tester vil jeg kunne velge å sette inn en av de tilgjengelige metodene Avsluttes uke 7, 13. februar 2009 Avsluttes uke 9, 27. februar 2009 Avsluttes uke 11, 13. mars 2009 Avsluttes uke 14, 3. april 2009 Avsluttes uke 17, 24. april 2009 Vedlegg A Arbeids- og iterasjonsplan 2

Som en tester vil jeg at highlighting og tilgjengelige metoder skal oppdateres hvis jeg angir ny klasse på øverste linje Som en tester vil jeg at nøkkelord i FitNesse skal vises med en egen farge Iterasjon 7 Eventuelt gjenstående og feilretting. Avsluttes uke 19, 8. mai 2009 Dokumentasjon/prosjektstyring: Oppgave Føre prosjektdagbok. Daglig dokumentering av hva som har blitt gjort. Møter/møtereferat. Møtereferat fra møter med intern og ekstern veileder/oppdragsgiver Prosessrapport. Dokumentasjon av hele prosessen. Se dokumentasjonsstandard. Produktrapport. Se dokumentasjonsstandard. Installasjons- og brukerveiledning Frist Føres kontinuerlig gjennom hele perioden. Leveres sammen med resten av dokumentasjonen 29. mai 2009. Føres kontinuerlig gjennom hele perioden. Leveres sammen med resten av dokumentasjonen 29. mai 2009. Trykk: 26. mai 2009 Leveres: 29. mai 2009 Trykk: 26. mai 2009 Leveres: 29. mai 2009 Trykk: 26. mai 2009 Leveres: 29. mai 2009 Avslutning: Oppgave Frist Forberede presentasjon 15. 17. juni 2009 Presentasjon 15. 17. juni 2009 Prosjektplakat 15. 17. juni 2009 Vedlegg A Arbeids- og iterasjonsplan 3

Vedlegg B Fremdriftsplan Vedlegg B Fremdriftsplan 1

Vedlegg C Forprosjektrapport Presentasjon Tittel: Experior Oppgave: Videreutvikle teksteditoren for test-verktøyet FitNesse med funksjonalitet som skal bidra til å gjøre det enklere og mer oversiktlig å skrive tester. Gruppemedlemmer: Peter Flem, s145638, 3AB, Terje Rongved Laugaland, s139794, 3AB og Robert Larsen, s141834, 3DB. Prosjektperiode: 5. januar - 29. mai 2009 Intern veileder: Geir Skjevling Oppdragsgiver: Bekk Consulting A/S Kontaktperson: Rune Flobakk Sammendrag Prosjektet gjennomføres som hovedprosjekt ved Høgskolen i Oslo, avd. for ingeniørutdanning våren 2009 i samarbeid med Bekk Consulting A/S, ved Rune Flobakk. Det skal utvikles en forbedret teksteditor til testverktøyet FitNesse (www.fitnesse.org). FitNesse er et verktøy som brukes til testing av applikasjoner, for at kunden, i samarbeid med utvikleren, selv skal kunne verifisere at systemet oppfyller kravene som er spesifisert. Pr. i dag er læringskurven for å ta i bruk teksteditoren som testene skrives i for bratt og fører i tillegg til at tester lett blir uoversiktlige. Prosjektet skal utvikles med Java og Javascript/AJAX. Dagens situasjon FitNesse kjøres som en webserver. Kommunikasjonen med brukeren skjer gjennom et webgrensesnitt, hvor man kan opprette, redigere og kjøre tester mot en applikasjon. Testene skrives ved hjelp av en wikisyntaks inn i en svært enkel teksteditor. Testene skrives på tabellform. I tabellene skriver testeren input til applikasjonen og hva som forventes som output. Når testen kjøres blir det sammenlignet hva som faktisk ble returnert fra applikasjonen mot det som var forventet. Hvis det som var forventet stemmer overens med det som ble returnert er testen passert og systemet fungerer etter kravet. FitNesse egner seg særlig til å teste krav som kan formuleres på tabellform (for eksempel talloperasjoner). FitNesse er særlig utbredt ved bruk av testdrevet utvikling og smidige utviklingsmetoder og brukes i dag blant annet hos Bankenes Betalingssentral, BBS. Gjennom FitNesse synliggjøres tester for Vedlegg C Forprosjektrapport 1

andre enn utviklere. For eksempel kan kunder bla rundt i tester, lese hva de utfører, og selv kjøre de for å verifisere at systemet faktisk oppfyller kravene de har spesifisert. De som skriver testene er ofte dedikerte testere uten programmeringsbakgrunn. I og med at testene i dag må skrives med en wikisyntaks er det en læringskurve for å være i stand til å skrive tester. I tillegg blir testene lett uoversiktlige, særlig i større tester. Mål og rammebetingelser Hovedmålet med oppgaven er ytterlig å tilgjengeliggjøre FitNesse for ikketekniske personer som skriver tester. Dette kan oppnås ved å implementere deler av følgende i FitNesses eksisterende webgrensesnitt: Forbedret tabellredigering ved at piper som brukes for å bygge opp tabellene automatisk alignes under hverandre. På denne måten blir tabellene, særlig større tabeller, mer oversiktlige. Autofullføring av variabel- og metodenavn, basert på programkoden som testen skal kjøres mot. Syntaks-highligting. For eksempel at metodenavn har en farge, input en annen farge og så videre. Det kan også være ønskelig å ha muligheten for å kunne velge andre fonttyper, størrelser og så videre. Tilrettelegge for økt gjenbruk av kode (det vil si tester). For å gjennomføre forbedringer som er mest mulig i tråd med det brukerne ønsker skal det gjennomføres intervjuer og observasjon av brukere/testere hos BBS. For å kunne være i stand til å implementere det som ønskes må vi som utviklere også kunne beherske FitNesse som testverktøy. Vi står veldig fritt i valg av teknologi og løsninger. FitNesse er skrevet i Java, og integrasjonen av vårt prosjekt i FitNesse må derfor gjøres i Java. Løsningen skal utvikles som åpen kildekode, på samme måte som FitNesse også gis ut med åpen kildekode. Som prosessmodell for utviklingen vil vi bruke Scrum, som er en agil metode. Vi valgte Scrum fordi Scrum er i utstrakt bruk som utviklingsmetodikk for mange store utviklerfirma, som for eksempel oppdragsgiveren vår Bekk Consulting. Ved hjelp av Scrums måte å jobbe på så føler vi det er lettere å drive utvikling ved at kravene blir brutt ned i flere små delmål, såkalte "user stories" med deloppgaver. Oversikt over hvilke trinn i prosessen hver oppgave befinner seg på fås gjennom en scrum-tavle hvor hver oppgave kan befinne seg i følgende trinn: "to do", "in progress", "verify" og "done". Dette gjør administreringen av fremdriften for oss oversiktlig og konsis. Etter hvert som vi får mer erfaring med Scrum så vil vi også eventuelt innføre såkalt "Scrum-Master" for å gjennomføre Scrum slik det for eksempel Vedlegg C Forprosjektrapport 2

blir gjort i Bekk Consulting. Vi er imidlertid litt usikre på om dette er passende i et prosjekt med kun 3 deltagere. Derfor tar vi i første omgang utgangspunkt i å gjennomføre iterasjoner med tavle og user stories. Oppdragsgiver ønsker ikke å fastsette fullstendige krav før implementeringen starter, men heller formulere user stories i løpet av prosjektperioden. De overordnene kravene/målene skissert ovenfor brukes som utgangspunkt og utdypes/konkretiseres til user stories underveis. Som utviklingsverktøy skal vi bruke Eclipse med plug-in for utvikling av JavaScript og støtte for versjonskontroll (SVN). Utviklingen skal gjennomføres testdrevet, med JUnit som rammeverk for enhetstesting. Som prosjektbygger benyttes Apache Maven. For hosting av kildekode brukes Google Code. For å holde oversikt over progresjonen brukes virtuelle Scrum-tavler på www.scrumy.com (direkte link til våre tavler er kun tilgjengelig for oss og ekstern/intern veileder). Prosjektarbeidet dokumenteres underveis med prosjektdagbok, som føres daglig, i tillegg til mer utfyllende møtereferat med eksterne/interne veiledere. Prosjektet skal leveres inn 29. mai 2009. Dette gir oss 21 uker til rådighet. Løsninger/alternativer For å oppnå hovedmålet med oppgaven er det hovedsakelig to valg, skissert av oppdragsgiver: 1. Plug-in til Eclipse. Her hadde det vært mulig å lage en egen Eclipsedistribusjon, uten Java-funksjonalitet, som kunne blitt benyttet av testere. Tilsvarende kunne utviklere hatt glede av FitNesse direkte i IDE-et. 2. Utnytte det eksisterende webgrensesnittet til FitNesse, og lage dette mer som en rik internettapplikasjon. Vi har valgt alternativ 2, det å utnytte FitNesses eksisterende webgrensesnitt. Årsaken til dette er først og fremst at det svært ofte er testere uten kunnskap om programmering som skriver tester. Det er derfor ikke nødvendig for disse å installere og bruke et IDE slik som Eclipse. Ved å inkludere dette i et IDE faller for så vidt noe av hensikten med FitNesse bort - nemlig det at personer uten programmeringsbakgrunn likevel skal kunne teste programkode uten nødvendigvis å måtte være i stand til å forstå koden. I tillegg er webgrensesnittet til FitNesse godt innarbeidet blant de som skriver tester i dag, og bidrar til at testere og utviklere lettere kan samarbeide om testene. Vedlegg C Forprosjektrapport 3

Analyse av virkninger For å oppnå hovedmålet er det først og fremst teksteditoren, som brukes til å skrive tester i, som det er aktuelt å gjøre forbedringer på. Som klientteknologi til selve editoren har vi valgt JavaScript/AJAX. Grunnen er at Ajax egner seg svært godt til funksjonalitet som autofullføring o.lign. Javascript/AJAX kjører på klienten og til slik funksjonalitet som vi har som mål å implementere vil det være lite behov for kommunikasjon med en server. Det må heller ikke startes opp egne plug-ins/applikasjoner (for eksempel Flash og lignende) for å kunne benytte editoren, noe som ville blitt sett på som lite hensiktsmessig av de som benytter FitNesse i dag. Det understrekes her at det kun er snakk som om at selve editoren skal skrives med JavaScript/AJAX. Som nevnt er FitNesse skrevet i Java og selve integrasjonen av "vår" editor inn i FitNesse må derfor gjøres i Java, tillegg til blant annet funksjonaliteten vedrørende autofullføring på variabel- og metodenavn fra koden som testen skal kjøres mot. Det finnes i dag flere ulike rammeverk som kan være aktuelle å benytte i utviklingen av editoren, for eksempel JQuery, DoJo og Google Web Toolkit. For å få størst mulig innsikt i kjerneteknologien (JavaScript/Ajax) planlegger vi i utgangspunktet ikke å benytte oss av slike rammeverk. Dersom det vil bety at løsningen vil bli dårligere ved å utelate bruk av slike rammeverk vil vi selvfølgelig vurdere dette dersom det skulle bli aktuelt. For å integrere den nye teksteditoren inn i eksisterende grensesnitt er det flere muligheter. Etter vårt skjønn vil den mest optimale løsningen være å lage editoren som en plug-in til FitNesse. Et annet alternativ er å gjøre endring i kildekoden og erstatte eksisterende teksteditor med vår editor, og dermed gjøre en egen distribusjon av hele FitNesse. Dette vil imidlertid være en ulempe når det kommer nye versjoner av FitNesse, noe som skjer flere ganger årlig. Dermed anbefales plug-in som enkelt kan installeres og fjernes uavhengig av hvilken versjon av FitNesse som benyttes. Vi ønsker ikke å erstatte den eksisterende editoren med vår editor, men gi brukeren mulighet til å velge hvilke som ønskes benyttet og mulighet til å skifte mellom editorene uten problemer. Oslo, 30. januar 2009 Terje Rongved Laugaland Peter Flem Robert Larsen Vedlegg C Forprosjektrapport 4

Vedlegg D Use case modell Nedenfor følger use case modell over Experiors hovedfunksjonalitet. Den har fungert som en konkretisering av krav og user stories der vi føler det har vært behov for det. I hovedsak har user storiene vært benyttet under utviklingen i det daglige. Use case Åpne test ønsker å åpne en test i Experior Det er lagret minst èn test 1. velger hvilke test han vil åpne 2. Testen vises i Experior. 3. Piper alignes etter mønster spesifisert i kravspesifikasjonen. 4. Kommentarer, metodenavn og nøkkelord highlightes. 5. Det vises oversikt over tilgjengelige metoder. 4A: Det er ikke angitt klassenavn på øverste linje i testen 1. Kun kommentarer og nøkkelord som skal highlightes 5A: Det er ikke angitt klassenavn på øverste linje i testen 1. Oversikt over tilgjengelige metoder skal være tom Vedlegg D Use case modell 1

Use case Lagre test ønsker å lagre en test som er skrevet i Experior Testen er lagret, og kan åpnes i standard-editoren. 1. velger å lagre testen. 2. Experior lagrer testen. Kun testdata skal lagres, ikke HTMLtagger som Experior benytter seg av. 1A: valgte å lagre og lukke. 1. Experior lagrer og lukker testen. Videresender testeren ut av Experior. 5B: valgte kun å lagre. 1. Experior lagrer testen, men testen skal fortsatt være åpen i Experior Use case Kommenter linje ønsker å kommentere ut en linje 1. skriver tegnet #. 2. All tekst etter dette tegnet på samme linje skifter farge. Tekstens størrelse skal ikke forandres, men fargen skal skiftes uavhengig av om teksten har farge fra før eller ikke. Funksjonen kan sammenlignes med om man skriver // i Eclipse. Vedlegg D Use case modell 2

Use case Kommenter flere linjer ønsker å kommentere ut flere linjer. 1. skriver tegnene {{{ før og }}} etter teksten som skal kommenteres ut. 2. Alle teksten mellom disse tegnene skifter farge. Tekstens størrelse skal ikke forandres, men fargen skal skiftes uavhengig av om teksten har farge fra før eller ikke. 1A: Brukeren har glemt å skrive et av tegnene 1. tekst skal kommenteres ut. Funksjonen kan sammenlignes med /* og */ i Eclipse. Use case Skriv overskrift ønsker å skrive en overskrift 1. skriver tegnet for overskrift. 2. Teksten etter dette tegnet, på samme linje, skifter farge og størrelse. Dette skal skje uavhengig av om teksten har farge eller spesiell størrelse fra før. 1A: Tegnet for overskrift kan være enten!1,!2 eller!3 1. Størrelsen på teksten skal variere, der!1 er størst og!3 er minst. Vedlegg D Use case modell 3

Use case Skriv nøkkelord skriver et nøkkelord 1. skriver inn et av nøkkelordene i FitNesse, enten reject, show eller check. 2. Nøkkelordet gis egen farge Use case Align pipe skriver en pipe 1. skriver en pipe. 2. Pipen plasseres umiddelbart rett under tilsvarende pipe på forrige linje. 2A: Det er ingen piper på forrige linje 1. Pipen plasseres der hvor markøren står 2B: Markøren befinner seg på øverste linje 1. Pipen plasseres der hvor markøren står Use case Align hele testen ønsker å aligne piper i hele testen En eller flere piper finnes i testen 1. velger å aligne piper i hele dokumentet. 2. Piper alignes etter spesifikasjonene som er definert i kravspesifikasjonen. Vedlegg D Use case modell 4

Use case Endre testklasse ønsker å teste mot en ny klasse, uten å lukke testen 1. skriver inn et nytt klassenavn på øverste linje i testen. 2. Experior sjekker om klassenavnet er gyldig og om klassen finnes. 3. Oversikten over tilgjengelige metoder oppdateres med metodenavn fra den nye klassen. 4. Metodenavn for den nye klassen skal highlightes. 2A: Klassenavnet er ikke gyldig 1. Oversikten over tilgjengelige metoder fjernes 2. Highlighting av eventuelt highlightede metoder fra den forrige klassen fjernes 2B: Klassen finnes ikke 1. Oversikten over tilgjengelige metoder fjernes 2. Highlighting av eventuelt highlightede metoder fra den forrige klassen fjernes Use case Sett inn metodenavn ønsker å sette inn et metodenavn Et gyldig klassenavn finnes på øverste linje i testen, og klassen finnes 1. en velger å sette inn et av metodenavnene som vises i oversikten over tilgjengelige metoder 2. Metodenavnet settes inn på posisjonen der tekstmarkøren står. 3. Foran metodenavnet skrives! 4. Etter metodenavnet skrives 5. Metodenavnet highlightes. Vedlegg D Use case modell 5

Use case Highlight metodenavn skriver inn et metodenavn Et gyldig klassenavn finnes på øverste linje i testen, og klassen finnes 3. skriver et metodenavn i testen. 4. Experior sjekker om metoden finnes i klassen som er angitt på øverste linje. 5. Metodenavnet highlightes etter spesifikasjonene i kravspesifikasjonen. 2A: Klassen inneholder ikke en metode med gitt navn 1. Metodenavnet skal vises som vanlig tekst uten farge Vedlegg D Use case modell 6

Vedlegg E Dataordbok AJAX Forkortelse for Asynchronous JavaScript and XML. Teknikk for å skifte ut deler av innholdet på en nettside, uten at det er nødvendig å laste hele siden på nytt. Les mer om AJAX i produktdokumentasjonen. Aligning Kan oversettes som justering. Ikke-justert tabell: 100 1000 1000 1 1 1 Justert (alignet) tabell: 100 1000 1000 Betastadiet En betaversjon av en applikasjon er den første versjonen som er gjort tilgjengelig for andre enn organisasjonen som har utviklet den. Dette gjør det mulig å gjennomføre tessting på reelle brukere, og det er ofte lagt til rette for at disse kan gi tilbakemelding til utviklerne. Betaversjoner inneholder som regel det meste av funksjonaliteten som er planlagt i den ferdige versjonen, men kan også inneholde flere kjente feil. DoFixture En type Fixture-klasse. Se Fixture-klasse. Eclipse Program for skriving og kjøring av programkode. Kan settes opp til å støtte de fleste språk. Se også IDE. Fixture-klasse Fungerer som limet mellom testene som skrives i FitNesse og den delen av systemet som skal testes. Skrives typisk av en utvikler. Det finnes forskjellige typer Fixture-klasser som kan benyttes, avhengig av hva slags funksjonalitet og system man tester. Se mer om ulike fixtures på www.fitnesse.info Vedlegg E Dataordbok 1

IDE Integrated Development Environment. Inneholder mulighet for å skrive, debugge, kompilere og kjøre programmer i samme program. Eksempler er Eclipse og NetBeans. Java Java er et plattformuavhengig, kompilert programmeringsspråk. JavaScript Script-språk som tolkes av nettleseren hos klienten. Script-språk vil si at det ikke kompileres, slik som for eksempel Java, men tolkes direkte under kjøring. Nøyaktig hvordan Javascript tolkes varierer fra nettleser til nettleser. Mer om JavaScript finnes i produktdokumentasjonen. Jar-bibliotek Programkode pakket til en fil (.jar), som andre utviklere kan gjøre bruk av. Funksjonaliteten som programkoden tilbyr kan dermed benyttes i andre prosjekter. JSON Format for utveksling av data. Lettere enn XML. Se produktdokumentasjonen for mer. JUnit Rammeverk for enhetstesting. Se testdrevet utvikling og produktdokumentasjonen for mer. Maven Verktøy for bygging og administrasjon av programmeringsprosjekter. Andre lignende verktøy er for eksempel Apache Ant. Se produktdokumentasjonen for mer. Piper Tegnet. I FitNesse brukes dette for å markere tabellkolonner. Plug-in Program som kan installeres som en separat del til et annet program, for å tilby økt funksjonalitet. Vedlegg E Dataordbok 2

Reflection API Inneholder mange metoder for å hente ut om og modifisere måten et program kjøres på. I dette prosjektet har vi bl.a. benyttet det for å hente ut metodenavn som finnes i gitte klasser. Repositories Kan oversettes som arkiv eller pakkebrønn. Subversion Forkortes SVN. Et system for versjonskontroll av programkode og dokumentasjon. Benyttes av de fleste kjente områder for hosting av open source prosjekter, som for eksempel SourceForge og Google Code. Se produktdokumentasjonen for mer. Syntaks highlighting Enkelte ord eller deler av teksten har en spesiell betydning. For eksempel metodenavn, kommentarer eller nøkkelord. For bedre lesbarhet og oversikt gjøres denne teksten forskjellig fra resten av teksten ved f.eks. annen størrelse, farge, fonttype osv. Testdrevet utvikling Måte å utvikle på der det først skrives en test i et rammeverk som f.eks. JUnit. Deretter skrives programkode som oppfyller kravene spesifisert i testen. Forkortes gjerne TDD. Se produktdokumentasjonen for mer. Wikisyntaks Bruk av diverse tegn for å oppnå ønsket utseende på teksten. Eksempelvis kan en overskrift, d.v.s. med større fontstørrelse enn vanlig tekst, angis med!1 foran teksten, mens tegnet brukes for å angi kolonne i en tabell. WYSIWYG Forkortelse for What You See Is What You Get. Eksempel på WYSIGWYGprogrammer er Microsoft Word og Adobe Dreamweaver. Kun innholdet i dokumentet er synlig for brukeren, ikke kode som sier noe om hvordan innholdet skal se ut. XML Er et strukturert format for deling av data. Benyttes særlig mellom systemer på Internett. Vedlegg E Dataordbok 3

Vedlegg E Dataordbok 4