Redigerer Wikisida.no:Lua (avsnitt)

=== Testing av Lua-moduler/funksjoner ===
Lua er et programmeringsspråk, og som alle slike er det mulig å gjøre feil. Under selve utviklingen av en modul er det viktig å teste på en effektiv måte, ikke minst for å unngå å introdusere feil i kode en har skrevet tidligere. Wikipedia er et stort kjøremiljø for kode, mye større enn det som er vanlig på andre nettstedere. Det er derfor overordentelig viktig at alt fortsetter å fungere som forventet etter endringer. Det er for å forenkle slik testing at det er laget egne testbiblioteker.

Generelt så blir testing gjort etter tre forskjellige paradigmer; [[enhetstesting]], [[testdrevet utvikling]], og [[oppførelsdrevet utvikling]]. Dels kan en se på disse tre som separate paradigmer, men de er nok like mye forskjellig tilnærming til hvordan en gjør testing.

==== Enhetstesting ====
Enhetstesting er helt konkret hvordan en tester en enhet, ofte ved å injisere forskjellige former for «spioner» i den kjørbare koden. Som oftest er enhetstesting tett knyttet til en bestemt implementasjon av en modul, og hvis en bytter modulen så bytter en også testsettet. Ofte er koblingen så tett at testsettet kan låse implementasjonen til en gitt løsning.

==== Testdrevet utvikling ====
Testdrevet utvikling går ut på at en definerer kontrakten for hvordan en metode skal oppføre seg før en skriver selve koden. Dette er en god løsning der en har en klar kravspesifikasjon på forhånd, eller hvor en kan utlede en slik kravspesifikaasjon. Problemet med dette er at når en skal løse et problem så er kravspesifikasjonen utenfor det en er mest fokusert på, dermed blir testspesifikkasjonen ufullstendig.

==== Oppførselsdrevet utvikling ====
Oppførelsdrevet utvikling er tettere på agile development, men med noen føringer på hvordan løsningen beskrives. Ved å bruke et nokså enkelt språk så tvinges en til å konkretisere nødvendig funksjonalitet og hva den skal utføre. Tradisjonell testing blir ofte gjort i etterkant, selv om dette er suboptimalt, mens ved oppførselsdrevet utvikling så defineres testene som en integrert del av kravspesifikasjonen.

==== Pragmatisk tilnærming ====
Det vi gjør i Wikipedia er veldig ofte at vi lager en første implementasjon, og deretter legger til tester for å bekrefte (verifisere) våre antakelser om koden. Etter hvert legges det til mer kode, og det legges til mer tester. Slik itererer vi oss fremover. Vi har ofte ikke en helt klar formening om hva vi gjør først, testing eller utvikling, og det finnes ingen klar bestiller av funksjonaliteten. Ulempen med dette er at vi kan ende opp med metoder og tester som ikke er optimale i fordi vi ikke har en klar kravspesifikasjon.

==== Tilgjengelige bibliotek ====
Hvordan vi tester er mer et metodevalg enn et valg av testbibliotek. Noen biblioteker lener seg litt mer til ett av paradigmene enn til de andre, men de som er tilgjengelig kan brukes for alle de tre skisserte. [[Modul:UnitTests]] er tett på overfladisk enhetstesting, hvor det essensielle er å ha noen primitiver for å teste likhet mellom input og output til og fra funksjoner. [[Modul:ScribuntoUnit]] er nok noe tettere på testdrevet utvikling, hvor en setter opp et testharness og itererer seg frem i vekselvirkning med koden som testes. [[Modul:BDD]] (''under utvikling'') har mest til felles med oppførselsdrevet utvikling og bruker elementer fra [[domenedrevet design]]. Denne modulen har noe støtte for tettere iterasjoner med koden som utvikles enn de to foregående modulene.

Modulene TestUnits er importert fra [[w:en:Module:UnitTests|enwiki]], mens ScribuntoUnit opprinnelig kommer fra [[w:hu:Module:ScribuntoUnit|huwiki]]. Modulen BDD er lokal her på [[w:no:Module:BDD|nowiki]]. Testtilfellene skrives på en underside «Moduldiskusjon:''modulename''/testtilfeller» hvor ''modulename'' er modulen som testes. Resultatene vises på undersidens diskusjonsside, «Modul:''modulename''/testtilfeller», eller ved integrasjon i testmodulens dokumentasjon, eller ved å bruke tilleggsfunksjonen [[Hjelp:Integrert testing]]. Denne viser testene på samme side som modulen når den åpnes for redigering.