Help:Pickle

Pickle portal
Hjem OSS Dokumentasjon Ordbok Rask tur med viktigste punkter Dokumentasjon Eksempler Hallo Verden (GitHub) Teknisk Extension:Pickle Programvaredokumentasjon Diverse Kilder (GitHub) Undersider

Warning:

Dette er under arbeid. Beklager det, til alle dere som ønsker å bruke fullverdige spec-tester i Lua med en gang!

Pickle er et prosjekt for å integrere kontinuerlig testing i et miljø for kontinuerlig integrasjon, slik som Wikipedia som bruker Lua-skript. På Wikipedia brukes Lua for å implementere avanserte maler, og samme løsning er brukt på mange andre nettsteder og prosjekter. Kontinuerlig testing er et kjerneelement i kontinuerlig levering, som er veldig viktig for nettsteder slik som Wikipedia som må være oppe og kjøre 24×7. Pickle bruker blant annet spec-type testing, som kan bli beskrevet som en variant av enhetstesting, eller hvordan lage (bygge) tingen rett. Hva som skal bygges, og hvordan bygge det, er ikke det eneste viktige. Det er også ekstremt viktig å redusere den samlede risikoen forbundet med å gjøre Lua-utvikling i et aktivt Mediawiki-prosjekt.

På engelsk er pickle en type grønnsak som har gjennomgått sylting, for eksempel sylteagurk, men som også er navnet på Gherkin-språket for å gjøre step-type testing. Samtidig så plukker du på koden, prøver på å dissekere den, i en kontinuerlig prosess for å finne feil og korrigere dem.

Bakgrunn

Testing lar oss si noe kvalitativt om programvaren, det vil si modulene i wikien, slik som antall og typer av kjente defekter, spesielt for funksjonelle krav. Det hjelper utviklerne å identifisere og fikse defekter under utvikling, men bygger også nettsamfunnets tiltro til den endelige modulen. Når noen senere ønsker å bruke modulen som del av en mal, da kan han sjekke resultatene, og muligens bli forsikret om at dette er faktisk en god modul før han kaller modulen fra malen. Hvis noe hender senere, muligens som følge av en feil i en annen inkludert modul, så vil forhåpentligvis testene identifisere de underliggende årsakene til problemet.

I denne løsningen, så kan alle lage de nødvendige testene, men det må forventes at brukeren som utviklet koden vil utvikle testene. Den brukeren vet best hva som må testes og hvordan teste det. Du aksepterer ikke halvferdig kode, og du bør heller ikke akseptere halvferdige tester. Likevel er det enkelt å glemme noen viktige tilfeller, og når du ser slike tilfeller så legg dem til! Bedre testdekning betyr færre defekter nå og i fremtiden.

Den grunnleggende ideen

Skjermskudd av «sidestatusindikatoren» når den viser et godt sluttresultatet av en testkjøring.

Når en tester (det vil si en pickle) har kjørt alle sine tester for et spesifikt testsubjekt (det vil si biblioteket eller modulen), og alle testene er godtatt, da vil den siden bli merket som godtatt både med en sideindikator og med en sporingskategori. Hvis tilstanden endres så vil det også bli lagd loggoppføringer. Hvis testene starter å feile av enhver grunn så vil de bli flagget som feilet av en sideindikator, og bli lagt i en kategori for feilede biblioteker. Hvis tilstanden endres fra en eller annen tilstand og til noe annet, da vil det også lages en loggoppføring. Sammen er dette den primære mekanismen for å spore feilende biblioteker.

Den ytre rammen (verden) skal kun prøve å teste et enkelt testsubjekt, og på grunn av dette så skal det kun være en enkelt describe. Det er fullstendig gyldig å ha flere, men det vil ikke egentlig gi mening når en tester enkeltbiblioteker. Dette kan bli omskrevet som en endring av kontekst, det vil si et kall til context, som vil implisere en endring av kjøremiljø for testsubjektet. En slik endring vil bli gitt en beskrivende tekst, hvor data trekkes ut av strengen. Disse ekstraherte databiter blir deretter omgjort til riktig type og gitt til rammen (verdenen). Vanligvis vil det ikke være nødvendig å lage separat kontekst og det vil bare finnes en describe og et antall it.

Anta at det er en modul for den allestedsnærværende "Hello World". Denne koden ser ut som eksempelkode 1

local p = {}
function p.hello()
    return 'Hello'
end
return p

Eksempelkode 1, et eksempel på den allestedsnærværende "Hello World". Det er ikke noe ekstraordinært med definisjonen denne modulen.

Koden for å teste denne modulen ser ut som eksempelkode 2

return describe 'the ubiquitous module for "Hello World"' (function()
	subject:hello()
	it 'shall reply with "Hello"' (function( str )
		expect( str ):toBeEqual()
	end)
end)

Eksempelkode 2, eksempel med en spec-type test. Det er (vil bli) både en implisitt og eksplisitt form av kall til subjekter.

Merk at den indre it tar en streng som argument, beskrivelsen, og at denne strengen har en indre streng "Hallo". Denne strengen blir levert til rammen (verden) og blir brukt i testen. Den ytre describe har også en indre streng i beskrivelsen, men denne blir ikke brukt.

Den første describe forsøker å koble testen til riktig bibliotek, det vil si testsubjektet, og vil lagre dette som subject. Dette kan bli testet ved å sammenligne den med en forventning. Denne forventningen er det som du ønsker en verdi fra subjektet skal være, ikke subjektet selv. Dette gjør det mulig å lage en modell av hva subjektet skal være. Du sammenligner modellen med subject, for å verdisette det på på noe vis. Hvordan denne verdisettingen blir gjort, og utfallet av den, blir deretter rapportert. Hvis verdisettingen er godtatt for alle verdisettinger, da vil totaltilstanden for testsubjektet bli satt til godtatt.

Utsagn som er sanne (oppverdi) vil bli uttrykt som expect et eller annet, men hva med utsagn som skal være usanne (downvalues) Disse utsagnene bruker en funksjon contradict. De er veldig like til expect, men den endelige verdisettingen er negert. Dette gjør det enkelt å lage utsagn som koden ikke skal tilfrestille. En nærmere inspeksjon avslører at hver test er en rad i et Karnaugh kart, hvor expect er rader med et sant utfall og contradict er de med usant utfall.

Fordi kolonnene i et Karnaugh kart representerer veivalg i koden, det vil si nodene i control flow graph, mens radene representerer verdisatte kanter, og da våre tester kun treffer en fraksjon av mulige verdisettinger, så må de faktiske verdisettingene være så representative som mulig.$refnote Vanligvis så vil vi legge mye arbeid i å identifisere grense-, kant- og hjørnetilfeller, men hvis koden er dårlig lagd så kan det være vanskelig og endatil umulig å sette alle alternative verdisettinger fra kolonnene. Ofte er det beste vi kan få til å forsøke å dekke flest mulig av veivalgene (valgdekning, «kanttilfeller»), det vil si at antall tester skal være av samme størrelsesorden som syklomatisk kompleksitet eller tett på men fortsatt mindre, eller hvis vi er eventyrlystne så kan vi forsøke å nå «uavhengige kanter» («kantdekning»).