Help:Pickle/nb

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. Senere vil Pickle muligens bli utvidet med step-type testing, eller hvordan bygge rett ting. 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 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, wants to use the module as part of a template, then (s)he 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 happens later on, possibly because of a defect in some other included module, then the tests will hopefully identify the root cause of the problem.

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. 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 fewer defects now and in the future.

Den grunnleggende ideen
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 gode, da vil den siden bli merket som god både med en sideindikator og med en sporingskategori. Hvis tilstanden endres så vil det også bli lagd loggoppføringer. If the tests start to fail for whatever reason it will be flagged as failed by a page indicator, and been put in a category for failed libs. If the state changed from some other state into a failed state, then there will also be a log entry. Together this is the primary mechanisms for tracking down failing libs.

The outer frame (world) should only try to tests a single testee, and because of this there should only be a single. It is completely valid to have several, but it won't really make sense while testing single libs. This can be rephrased as a change of, which would imply a change of data provided to the testee. Such a change will be given as a descriptive string, where data is extracted from that string. Those extracted data snippets will then be cast to correct type and provided to the frame (world). Most of the time it will not be necessary to create separate context and it will only be a  with a number of.

Assume that there is a module for the ubiquitous "Hello World". This code looks like the example code 1

Example code 1, an example of the ubiquitous "Hello World". There is nothing extraordinary with the definition this module.

The code for testing this code looks like the example code 2

Example code 2, example of a spec-style test. There is (will be) both an implicit and explicit form of calls on subjects.

Note that the inner  takes a string as argument and that this string has an inner string "Hello". This string is delivered to the "frame" ("world") and is used in the test. The outer  has also an inner string in the description, but this is thrown away.

The first  tries to attach the test to the correct lib, that is the testee, and will store this as the. This can be tested by comparing it to an expectation. The expectation is what you want a value from the subject to be, not the subject itself. This makes it possible to make a model of what the subject should be. You compare the model with the, to valuate it in some respect. How the valuation is done, and its outcome, is then reported. If the valuation is good for all valuations, then the overall state for the testee is set as good.

Statements that are truthy will be stated as  something, but what about statements that should be falsy? Those statements use a function. They are very similar to, but they have their final valuation negated. This makes it simple to make a statement that the code should not fulfil. A closer inspection reveals that each test is a row in a Karnaugh map, with  being rows with a truthy outcome and   those with a falsy outcome.

Because the columns in a Karnaugh map represents the branching decisions in the code, that is the nodes in a control flow graph, while the rows represents valuated paths, and that our tests only hits a fraction of the possible valuations, the actual valuations must be as representative as possible. Usually, we will put great effort into identifying border and corner cases, but if the code is badly written it could be very difficult or even impossible to hit all alternate valuations from the columns. Often the best we can do is to try to cover most of the branches (branch coverage, "edge cases"), that is the number of tests should be of the same order as cyclomatic complexity or close to it but still lower, or if we are adventurous we can head for independent paths (path coverage).