Help:Pickle/nb

'This is a page describing a proposed solution. It is not finalized, but an on-going work.'''

Sorry about that, to all those that want to do full spec-tests in Lua right away!''

''At some point this extension will probably be renamed, most likely to "pickles". You pick on something, and use gherkin-like languages, so pickles seems like a good name.''

Spec er et prosjekt for å lage et miljø for kontinuerlig testing av Lua-skript, som er brukt for å implementere avanserte maler. Kontinuerlig testing er et kjerneelement i kontinuerlig levering, som er veldig viktig for nettsteder slik som Wikipedia som må oppe og kjøre 24×7. Spec-type testing kan bli beskrevet som en variant av enhetstesting, eller hvordan lage (bygge) tingen rett. What to build, and how to build it, is not the only important thing. It is also utterly important to reduce the overall risk associated with running live Lua development within an active Mediawiki project.

Background
Testing allows us to say something qualitative about the software, that is the modules in a wiki, such as the number and type of known defects, especially for functional requirements. That helps the developers to identify and fix defects during development, but also builds the community’s confidence in the final module. When someone later on want to use the module as part of a template, then she can check out the results, possibly being assured that this is in fact a good module, before calling the module as part of the template. If something happen later on, possibly because of a defect in some other included module, then the tests will hopefully identify the root cause of the problem.

In this solution anyone can make the necessary tests, but it should be expected that the user developing the code would also develop the tests. That user knows best what to test and how to test it. You don't accept half-done code, you should neither accept half-done tests. Still it is easy to forget some important cases, and when you see such cases do add them! Better test coverage means less defects now and in the future.

Rask tur
Hvordan sette opp og bruke tester, kjøre dem interaktivt og tolke rapportene. Noen konsepter er beskrevet på Help:Spec/Grunnleggende idé, men den er bare en veldig grov og forenklet beskrivelse. Det er noen spesifikke termer angående specer generelt, og spesielt for bruk på wikier. De har blitt definert i.

Avanserte verktøy
Noen avanserte verktøy er tilgjengelig, for spesielle formål. De har blitt gruppert etter disse temaene:


 * Specenes dokumentasjonsside kan bli gitt en spesiell mal som ikke bare rapporterer resultatet på dokumentasjonssiden, men som også kategoriserer siden hvis testene feiler.
 * Specenes dokumentasjonsside kan bli gitt en spesiell mal som ikke bare rapporterer resultatet på dokumentasjonssiden, men som også kategoriserer siden hvis testene feiler.


 * Både test- og kildesider kan kjøre tester i konsollet. På testsiden så vil kun et enkelt testsett bli kjørt, men på kildesiden vil alle undersider som gjenkjennes som specsider bli kjørt.
 * Både test- og kildesider kan kjøre tester i konsollet. På testsiden så vil kun et enkelt testsett bli kjørt, men på kildesiden vil alle undersider som gjenkjennes som specsider bli kjørt.

Under arbeid

 * En underside er funnet og kalt som del av en tolket melding. Dette oppslaget og tolkingen gjør det mulig å definere en lokalisert tilbakefallskjede, eller endog inkludere og tolke nye testrammeverk.
 * En underside er funnet og kalt som del av en tolket melding. Dette oppslaget og tolkingen gjør det mulig å definere en lokalisert tilbakefallskjede, eller endog inkludere og tolke nye testrammeverk.


 * Den tolkede teksten fra undersiden vil bli prosessert av en enkel akstraktor for å se om det er mulig å identifisere bestemte termer og fraser. Hvis noen er funnet så vil et bestemt merke bli satt forut for videre prosessering.
 * Den tolkede teksten fra undersiden vil bli prosessert av en enkel akstraktor for å se om det er mulig å identifisere bestemte termer og fraser. Hvis noen er funnet så vil et bestemt merke bli satt forut for videre prosessering.


 * Testrapporten kan være det endelige merket brukt av utvidelsen, men det kan også være gitt av Test Anything Protocolen. Den vil da gjøre et forsøk på å omskrive tap-rapporten til det endelige merket.
 * Testrapporten kan være det endelige merket brukt av utvidelsen, men det kan også være gitt av Test Anything Protocolen. Den vil da gjøre et forsøk på å omskrive tap-rapporten til det endelige merket.


 * Alle moduler som har specs vil ha ha en sideindikator for det nåværende resultatet av testene, både som del av symbolet (ved fargen) og meldingen (som tekst).
 * Alle moduler som har specs vil ha ha en sideindikator for det nåværende resultatet av testene, både som del av symbolet (ved fargen) og meldingen (som tekst).


 * Alle moduler som har specs vil ha en sporingskategori for det siste resultatet av testene. Den vil følge resultatet som blir vist av sideindikatoren.
 * Alle moduler som har specs vil ha en sporingskategori for det siste resultatet av testene. Den vil følge resultatet som blir vist av sideindikatoren.


 * Alle moduler som har specs vil legge til oppføringer på testlogg for nåværende resultat av testene. De vil følge resultatet som blir vist av sideindikatoren.
 * Alle moduler som har specs vil legge til oppføringer på testlogg for nåværende resultat av testene. De vil følge resultatet som blir vist av sideindikatoren.


 * Det er mulig å kalkulere programvaremål for modulene, og spesielt syklomatisk kompleksitet er veldig interessant mål fordi det gir øvre og nedre grenser for antall nødvendige tester.
 * Det er mulig å kalkulere programvaremål for modulene, og spesielt syklomatisk kompleksitet er veldig interessant mål fordi det gir øvre og nedre grenser for antall nødvendige tester.