Help:Pickle/Glossary

Glossary for pickle tests is a list of core terms and concepts, both for spec and step style tests.

Terms and concepts

 * After
 * Also known as teardown.
 * Marks functions to be run after describe>#describe|describe, context>#context|context, and it>#it|it. 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 after>#after|after that is only run if the test throws an exception>#exception|exception. If an exception is thrown, and there is an around function registered, then no after function will be run.


 * Assertion
 * Test that focuses on the actual code, and assertions about that code, and their falsy conditions. In depth article on Assertion.


 * Before
 * An alias for this is setup.
 * Marks functions to be run before describe>#describe|describe, context>#context|context, and it>#it|it. 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 spy>#spy|spy like carp>#carp|carp, but also prints a stack trace starting one level up.


 * Condition
 * A logical expression that can be evaluated as True or False, e.g., A>B.


 * Confess
 * A spy>#spy|spy like carp>#carp|carp, and is an alias for.


 * Context
 * Marks functions used as examples. See example>#example|example for details.


 * Coverage
 * The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.


 * 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 spy>#spy|spy like carp>#carp|carp, 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 <tvar|1></>


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


 * Fixture
 * The function defining the test is the test fixture, and a frame without a test fixture it will be skipped.


 * 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 <tvar|1></> for details.


 * Mock
 * A simulated object that act as a strictly controlled replacement for a real object. A mock is a type of test double.  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 data structures in source code.


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


 * Skip
 * The system (or optionally the author) can mark a test as skipped, either in the description or in the code. Further processing within the frame will then be terminated and the current state used. That imply that a test skipped before first assertion will be "not ok", while skipped after passed assertions will be "ok". ; Spec
 * A type of testing to make sure we build the thing right, usually by writing some kind of unit tests, but can also be more high level.


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


 * Step
 * A type of testing to make sure we build the right thing, usually by writing some kind of acceptance tests, which is at the integration level.


 * 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 <tvar|1></>


 * Todo
 * The user (or optionally the system) can mark a test as todo, either in the description or in the code. Further processing within the frame will then be terminated and the current state used. That imply that a test with todo before first assertion will be "not ok", while a todo after passed assertions will be "ok".