Mange av oppgavene på denne wiki'n lenker til JExercise-tester, slik at en kan teste koden en skriver undervies og se om den tilfredsstiller kravene i oppgaven. jextest er et eget språk, som er bygget på Java og som kan brukes for å skrive slike tester. Målet med jextest er tredelt:
- gjøre testene lettere å forstå - logikken bak testene skal kunne leses og forstås godt nok til at en både skjønner hva og hvordan ens kode testes og forstår feilmeldingene en får når testen oppdager feil
- gjøre det raskere å skrive tester - for å kunne produsere et stort utvalg av oppgaver med tilhørende tester er det viktig at det ikke tar lang tid å skrive en test
- senke terskelen for å skrive tester - det er fint om læringsassistenter og andre med mindre erfaring kan bidra med oppgaver og tester
jextest er basert på idéen bak objekttilstandsdiagrammer: at objekter forandrer tilstand ved kall på metoder og at oppførselen kan spesifiseres/beskrives med eksempler på sekvenser av slike tilstandsoverganger. Hvis man har tegnet et objekttilstandsdiagram som er dekkende for forventede oppførsel, så skal det å kode en test på at denne oppførselen er korrekt implementert være nokså rett frem.
Oppførselen til Counter-klassen fra Tilstand og oppførsel kan for eksempel beskriveses med følgende diagram og testes med jextest-koden til høyre
test stateandbehavior.Counter
instance Counter counter = new Counter(1, 3)
sequence example {
-->
state {
getCounter() == 1
}
-- count() -->
state {
getCounter() == 2
}
-- count() -->
state #final {
getCounter() == 3
}
-- count() --> #final
}
| Diagrammet helt til venstre illustrerer oppførselen til Counter-klassen ved å vise hvordan et Counter-objekt endrer tilstand når count()-metoden kalles, inntil counter-verdien har nådd slutt-verdien (end). jextest-koden til venstre beskriver hvordan en instans opprettet med new Counter(1, 3) drives gjennom en sekvens med tilstander ved kall til count()-metoden, inntil siste tilstand gjentas. jextest-koden er på en måte en tekstlig formulering av diagram-logikken, som kan oversettes til Java og utføres som en vanlig JUnit-test. Hver sekvens oversettes til én test-metode som utfører koden i transisjonene og tester tilstanden før og etter. F.eks. vil sekvensen med navn example i eksempet gi opphav til metoden testExample(), som JUnit-rammeverket gjenkjenner som en testmetode. Hver tilstand er en sekvens med (som oftest logiske) uttrykk, som oversettes til kall til en assert-metode (akkurat hvilken avhenger av typen uttrykk). Koden for uttrykk og setninger som brukes i transisjoner og tilstander følger syntaksen til Xbase-språket (del av Xtext-rammeverket), som gir kompakt og lettlest kode.
|
Hovedstruktur
Strukturen til en jextest-fil er som følger:
test <navn på klasse som testes> [with <navn på testklasse>] [<beskrivelsestekst>] [@ <nettadresse>] | test-deklarasjonen inneholder som regel bare navnet på klassen som testes, men en kan også eksplisitt angi navnet på testklassen som genereres. I tillegg kan en legge inn en beskrivelse/dokumentasjonstekst og en nettadresse, f.eks. til wiki-siden for oppgaven. test-deklarasjonen etterfølges av en import-del og en eller flere instance-, state-, sequence- og method-deklarasjoner. |
| import <type> | |
| instance ([<type>] <navn på instans>)+ | instance-delen inneholder én eller flere instance-deklarasjoner som lister opp type og navn til instansene som testes. Hvis typen ikke oppgis, så brukes typen til klassen som testes. Hvis en bare trenger én instans, så kan hele instance-delen utelates. En får da én instans med samme navn som typen, men med liten forbokstav, slik konvensjonen er. |
| state [<type>] <navn> (<argumentliste>) { <uttrykk>* } | state-delen inneholder én eller flere state-deklarasjoner som definerer tilstandsfunksjoner. En slik funksjon er som en vanlig brukes i test-sekvensene for å gjøre dem kortere, angir type, navn og argumentlista til på en |
| sequence <navn> { (<før-tilstand> <transisjon>)+ <ettertilstand> } | |
| method |
fds