Help:Pickle/Expect

There is a test-lib based on expectations, that is a we say what the subject is expected to do, not what is a failed response. This is slightly different from the |assert style testing libs. Expectations are common in several testing frameworks, but the style implemented has its own quirks to make it work in our environment.

The main difference is that while an assertion says whats wrong and stops execution, and expectation says whats right and continue execution. In addition to that there are some magic behind the scenes to allow the subjects to be set up for testing.

Note that part of the naming scheme is slightly odd and should perhaps be changed. The call  should not set the subject but the expectation. Not quite sure whats easier to understand.

Core idea
There are three access functions;,  , and. They act as accessors to several internal structures by holding the necessary closures.

Note that there are several ways to implement objects in Lua, but we can assume that objects we want to test will be based on tables. By implementing additional accessors we can test other types of objects too, but most of the time we we will be testing tables.

Assume we have a rather simple library  on the form

This i pretty typical for most libraries, and we can include it in other libraries as

This can be used in a test fixture as

or simply as (both forms work)

Note that you should not use a form  as this will not work. This creates a local variable, while what we want is to assign the required lib to an existing variable. What we really do is to assign to a table.

At this point we have set up the library for testing, but note one important thing; we are testing the object returned from the library and if that maintain a state it will be retained from call to call. We may say that we are testing a specific instance of the object and not the library.

In its simple form it is already ready for testing. The instance submerges in the  call and emerges in the   structure, and we can add a simple test

If we have made a test we do want to know what is going on. To do that we can pull the report. Because we are in a Mediawiki-context we do that by providing the reports to

In some cases we want to test something that is not part of the provided implicit setup. Instead of calling  on each case, it is possible to override the subject from   by using the call-syntax

It is even possible to create a table instance inline this way

Preprocesses
Preprocesses or conditioners are those methods that are run before the similarity test, which is our idea of what is a correct answer. After the similarity test there are additional postprocesses to transform the test into our final outcome. That makes it possible to do a positive identification of a state and then negate that state, which is often easier to do that to test on the negative outcome.

Picks
Because functions may return multiple values there is a number of methods to extract a specific value. Typical calls looks like

The methods are named
 * first
 * second
 * third
 * fourth
 * fifth
 * sixth
 * seventh
 * eight
 * ninth
 * tenth
 * eleventh
 * twelfth

Formatters
To make