Help:Pickle/Glossary

Glossary for spec tests is a list of core terms and concepts used in spec tests.

Terms and concepts

 * After
 * Also known as teardown.
 * Marks functions to be run after, , and . It uses a single queue so all functions will be run in the correct sequence.


 * AfterAll
 * Marks functions similar to, except it is run once.

Strictly speaking this function is not necessary as code can be added inline. It use a single queue so all functions will be run in the correct sequence. It use the same queue as after so it will be run at the correct time in the first test. At later invocations it will not be run.


 * Around
 * An alternate to that is only run if the test throws an.

If an exception is thrown, and there is an around function registered, then no after function will be run.


 * Assertions
 * Tests that focuses on the actual code, and assertions about that code, and their falsy states.

In depth article on Assertion (software development).


 * Before
 * An alias for this is setup.
 * Marks functions to be run before, , and . It use a single queue so all functions will be run in the correct sequence.


 * BeforeAll
 * Marks functions similar to, except it is run once.

Strictly speaking this function is not necessary as code can be added inline. It use a single queue so all functions will be run in the correct sequence. It use the same queue as before so it will be run at the correct time in the first test. At later invocations it will not be run.


 * Carp
 * A that adds a message to stack without exiting the test, printing the caller's name and its arguments.


 * Cluck
 * A like, but also prints a stack trace starting one level up.


 * Confess
 * A like, and is an alias for.


 * Context
 * Marks functions used as examples. See  for details.


 * Coverage

The degree to which a test or tests addresses all requirements for the system under test.


 * Criteria

What the system under test must satisfy in order to pass a given test. In specs it is only used simple pass/fail.


 * Croak
 * A like, but also stops the running test (the user provided anonymous function).  Because it throws an exception it will always trigger a stack trace.


 * Describe
 * Marks functions used as examples. See  for details.


 * Design
 * Also known as test design

The document that describes the implementation details of the test, or results of, the system or in our case the module. The document is a subsection on the  subpage for the spec page.


 * Developer
 * A person that write code. See 


 * Documentation
 * Also known as test documentation

The document that describes plans of, or results of, the system or in our case the module. The document is the  subpage for the spec page.


 * Examples
 * The levels in the describe, context, and it ladder. The name and level are a bit arbitrary as they all have the same function.  The context is often left out, and only describe and it are used.


 * Exceptions
 * Error states reported from within the code. They will be caught by the test framework.

In depth article on Exception handling.


 * Expectations
 * Tests that focus on the provided objects and examples, and their truthy states.


 * Harness

Scaffolding code written for the purpose of exercising low-level code, in place of the high-level code.


 * It
 * Marks functions used as examples. See  for details.


 * Mock

A simulated object that act as a strictly controlled replacement for a real object.

A mock is a type of.

In depth article on Mock object.


 * Overfitting

Happens when there are too tight couplings between the test and source code. Usually happen when tests use spies to verify internal datastructures in source code.


 * Return
 * The outermost zero-level that encapsulates the test results and returns them in a formatted fashion.


 * Spies
 * Functions that can be registered on other functions, or injected into code to report or alter internal states. Spying on public calls made before the module is available to the testing regime will not be possible.


 * Stub

Simulated code, usually a function in this context, that acts as a strictly controlled replacement for some real code.

A stub is a type of.

In depth article on Test stub.


 * Subject
 * The object under test. It can be explicitly set or set as part of the .  It is passed on to.


 * Test

An activity to verify proper operation of a system, given that it is executed under specific conditions, and with observed and recorded results.


 * Test case
 * A set of inputs, conditions, and anticipated results for a particular objective. Can also include documentation for how to run the test case.


 * Test doubles

Code replacing pieces of code that are not tested, and should return only known values.

In depth article on Test double.


 * Test item

An item that is the object of some test effort.


 * Tester

A person that writes code. See 