3. Experior - rich test editor for FitNesse -
3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav og anbefalinger til utviklingsprosess og dokumentasjon. Dokumentet er beregnet på sensorer og veiledere som skal evaluere prosjektet. I tillegg har den fungert som en overordnet rettesnor for oss som utviklere og oppdragsgiver gjennom prosjektet. Kravene har blitt formulert underveis i prosessen, både av oss og oppdragsgiver, og var ikke fastsatt ved prosjektstart. Mer om denne fremgangsmåten finnes i prosessrapporten. For best mulig sammenheng og forståelse anbefales det at dokumentet leses kronologisk. 2
3.2. Innhold 3.1. Forord... 2 3.2. Innhold... 3 3.3. Innledning... 4 3.3.1.Presentasjon... 4 3.3.2.Bakgrunn... 4 3.4. Generelt... 4 3.5. Kompetansekrav... 4 3.6. Funksjonelle krav... 5 3.7. Kompatibilitetskrav... 8 3.8. Dokumentasjon og lisenser... 8 3
3.3. Innledning 3.3.1. Presentasjon Tittel Experior rich test editor for FitNesse Gruppemedlemmer Peter Flem, s145638, 3AB Terje Rongved Laugaland, s139794, 3AB Robert Larsen, s141834, 3DB. Prosjektperiode 5. januar - 29. mai 2009 Intern veileder Geir Skjevling geir.skjevling@iu.hio.no Oppdragsgiver Bekk Consulting A/S Kontaktperson Rune Flobakk rune.flobakk@bekk.no 3.3.2. Bakgrunn 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, med navn Experior, til testverktøyet FitNesse (www.fitnesse.org). FitNesse brukes for testing av applikasjoner Den nye editoren skal tilby støtte til brukeren i form av blant annet syntaks highlighting, autofullføring og forbedret støtte for tabellredigering. Det tas utgangspunkt i behov og ønsker fra brukere av FitNesse hos Bankenes Betalingssentral, BBS. 3.4. Generelt Eksisterende editor og arbeidsmåte er godt innarbeidet blant de som jobber med FitNesse i dag. Det er derfor ikke ønskelig at den nye editoren skal innføre totalt nye måter å gjøre ting på, snarere en forbedring av eksisterende arbeidsmåter. 3.5. Kompetansekrav For å være i stand til å gjennomføre de krav som spesifiseres er det nødvendig for oss som utviklere å sette oss inn i, for oss, nye teknologier og språk. I samarbeid med oppdragsgiver er det bestemt at produktet skal utvikles ved hjelp av følgende: 4
JavaScript (herunder AJAX) Java I prosessen benyttes følgende: Eclipse Apache Maven JUnit SVN 3.6. Funksjonelle krav Experior skal bestå av følgende funksjonalitet: Mulighet til å angi hvilke Fixture-klasse det skal testes mot Et klassenavn regnes som (eksempel): pakke.minpakke.minklasse. Klassenavn skrives direkte inn i testen. Hvilken klasse som skal testes skal kunne angis på følgende måter: 1.!*****> Oppsett! pakke.minpakke.minklasse *****! Klassenavnet skal her alltid være den første linjen med tegn under linjen med!***> osv. 2.! pakke.minpakke.minklasse 3.! -pakke.minpakke.minklasse- For punkt 2 og 3 skal disse klassenavnene gjenkjennes kun hvis de står på øverste linje i testen. Syntaks highlighting 1. Alle metodenavn som finnes i klassen som skal testes (se forrige punkt) skal highlightes, det vil si på en eller annen måte skille seg fra øvrig tekst, dersom de skrives inn i en test. Følgende måte å skrive metodenavn i en test på skal aksepteres: tallene plus skal bli! tallene plus skal bli! tallene <et tall> plus <et tall> skal bli <et tall> (et vilkårlig antall tall kan skrives inn, uavhengig av plassering) Enkeltord skal ikke highlightes. Det vil si at hvis for eksempel tallene står i en annen sammenheng enn en av de tre nevnt ovenfor skal det ikke highlightes. 5
2. Det skal være mulig å kommentere ut deler av testen. Det gjøres med {{{ og }}}. Disse kan settes på ulike linjer og på tvers av alle tabeller og tekst. All tekst mellom disse skal markeres med en egen farge. Dette gjelder også dersom teksten har blitt highlightet tidligere tidligere highlighting skal da overskrives. Det skal også være mulig å kommentere ut enkeltlinjer med tegnet # på starten av en linje. 3. Det skal være mulig å sette overskrifter. Dette gjøres ved hjelp av!1,!2 osv., der 1 har størst størrelse, 2 mindre osv. Overskrifter fra og med 1 til og med 3 skal gis større størrelse og egen farge. Dette skal skje automatisk hvis brukeren skriver et! etterfulgt av tall fra 1-3. Selve utropstegnet og tallet skal ikke highlightes. 4. FitNesses nøkkelord reject, show og check skal gis egen farge. Aligning av piper Med aligning menes at piper på en linje plasseres på tilsvarende sted som på linjen over/under. Eksempel: 1. Ved åpning av en eksisterende test. Ved åpning skal alle piper i dokumentet alignes etter følgende regler: - Piper på første linje i en test skal ikke alignes - Dersom linjen over en annen linje er tom, eller ikke inneholder piper, skal eventuelle piper på denne linjen ikke alignes. - Dersom linjen begynner med! skal den ikke alignes. - Piper i hver tabell i en test skal alignes individuelt. En tabell begynner med enten! eller. Første linje i tabellen skal ikke alignes. Deretter skal piper fra linje 2 og nedover alignes likt. 2. Underveis i redigeringen. Det skal være mulig å aligne hele dokumentet på nytt mens man redigerer testen. Dette skal skje etter tilsvarende regler som nevnt i forrige punkt. 3. Mens man skriver. Hvis det skrives en pipe skal denne plasseres automatisk på samme posisjon som neste pipe på forrige linje, sett fra der markøren står. Dersom forrige linje er tom, eller hvis markøren befinner seg på første linje, skal pipen plasseres der markøren står. 6
Metodeoversikt og autofullføring Alle metodenavn i klassen som skal testes skal presenteres for brukeren. De skal presenteres som vanlig tekst. Det vil si at dersom metoden heter minmetode() skal dette presenteres som min metode. Metodenavn til klassens superklasser skal også presenteres. Dette skal skje for alle klasser opp til klassen før superklassen DoFixture, som alle DoFixture-klasser må arve. Det skal ikke settes begrensninger på antallet metoder en klasse kan ha, det vil si antall som kan vises i oversikten. Det skal være mulig for brukeren å sette inn en eller flere av de tilgjengelige metodene, uten å måtte skrive dette manuelt. De skal da settes inn der markøren står, og testen skal verken scrolle opp eller ned dersom dette gjøres. Metodenavnet highlightes og skrives med! foran og etter. Lagring Det skal være mulig å lagre alle endringer som blir gjort i testen. Brukeren skal gis valget mellom kun å lagre, for deretter å bli stående i samme test, eller både å lagre og lukke testen. En test lagres som ren tekst i en vanlig tekstfil. Alle tegn og eventuelt annet som brukes for å oppnå highlighting, aligning og så videre i Experior skal da fjernes før det skrives til fil. Det vil si at Experior ikke skal påvirke selve dataene, kun presentasjonen av dem. Men dersom det er gjort endringer i selve dataene, det vil si innholdet i testen, skal dette selvfølgelig lagres. Øvrig Det skal være mulig å lime inn tekst i Experior med Ctrl+V. Det skal være mulig å kopiere tekst fra Experior med Ctrl+C og klippe ut med Ctrl+X. Her gjelder samme prinsipp som for lagring, kun testdata skal tas med, ikke eventuelle andre tegn som benyttes av Experior. Tilgjengelighet Experior skal være et alternativ til eksisterende editor, og skal ikke erstatte den. Brukeren skal gis tilgang til Experior på en lett og forståelig måte. Automatisk oppdatering Dersom brukeren foretar en endring i øverste linje, for eksempel bytter klassenavn, skal det automatisk sjekkes om det fortsatt er et gyldig 7
klassenavn og om denne klassen finnes. Hvis så er tilfellet skal det hentes metodenavn fra den nye klassen (og dens subklasser). Oversikten over tilgjengelige metoder og highlightingen skal da oppdateres uten at testen lastes på nytt. Dersom det ikke er et gyldig klassenavn, eller klassen ikke finnes, skal da oversikten tømmes og highlightingen av eventuelle metodenavn fjernes. For forslag til ytterligere funksjonalitet henvises det til øvrig dokumentasjon. 3.7. Kompatibilitetskrav FitNesse er et gratis verktøy med åpen kildekode som jevnlig kommer i nye versjoner. Experior skal distribueres uavhengig av selve FitNesse, og skal kunne benyttes som en plug-in. Det innebærer at det ikke skal være nødvendig å gjøre endringer i kildekoden til selve FitNesse for å ta Experior i bruk. Installasjonen av Experior skal være tilpasset for å enkelt kunne tas i bruk i oppdragsgivers eksisterende utviklingsmiljø. Brukeren skal kunne veksle mellom å bruke eksisterende editor og Experior etter eget forgodtbefinnende. Tester som er opprettet eller endret i Experior skal vises som før, det vil si som helt ren tekst uten noen formatering eller annet innhold enn selve testen, i den eksisterende editoren. Tilsvarende skal tester som er opprettet eller endret i den eksisterende editoren vises med all ønskelig aligning, highlighting og så videre dersom den vises i Experior. Experior skal kunne benyttes i Mozilla Firefox. Eventuell støtte for andre nettlesere blir sett på som en bonus, men er ikke noe krav. 3.8. Dokumentasjon og lisenser Experior skal utvikles som åpen kildekode med en lisens som setter få eller ingen begrensninger for videre bruk., SVN skal benyttes for hosting av kildekode og versjonskontroll. Alle som ønsker det skal kunne hente fullstendig kildekode til Experior herfra. Kildekoden skal skrives med mest mulig selvforklarende variabel- og metodenavn for at det skal være lettere for andre som eventuelt skal drive videreutvikling. Det skal benyttes engelske navn på variabler og metoder. Den delen av utviklingen som gjøres i Java skal gjøres testdrevet. 8
Videre skal det skrives produktdokumentasjon, prosessdokumentasjon og brukerveiledning i henhold til dokumentasjonsstandard for hovedprosjekter ved Høgskolen i Oslo. Det er for øvrig ikke noen spesielle krav til dokumentasjon fra oppdragsgivers side, verken i form av eksempelvis UMLdiagram, teknisk dokumentasjon eller lignende. 9
10