Help:Pickle

Pickle is a project to integrate automated testing into an environment for continuous integration, like Wikipedia which use Lua-scripts. Within Wikipedia Lua is used to implement advanced templates, and the same solution is used on a lot of sites and projects.

Continuous integration is a core element of continuous deployment, which is very important for sites that must be up and running 24×7.

Pickle use among other spec-style testing, which can be described as a variant of unit testing, or how to make the thing right.

Later on, Pickle might be extended with step-style testing, or how to build the right thing.

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.

In English a pickle is a type of vegetable that has undergone pickling, such as a gherkin, which also happen to be the name of the Gherkin language to do step-style testing. At the same time you pick on some code, trying to dissect it, finding flaws and correcting them in a continuous process.

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, 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.

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

Basic idea


When a tester (that is a pickle) has run all its test for a specific testee (that is the lib or module), and all the tests are good, then that page will be flagged as good both by a page indicator, and by a tracking category. If the state changes then there will also be created log entries. 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).