Aide:Pickle/Glossaire

From mediawiki.org
This page is a translated version of the page Help:Pickle/Glossary and the translation is 29% complete.

Le Glossaire pour les tests de Pickle est une liste de termes et concepts fondamentaux, à la fois pour les tests de style #spécifications et #étape. Les termes sont issus des cadres de travail de l’ITIL, de l’ISTQB et de RSpec, ainsi que de la logique des prédicats. Les différents cadres de travail sont liés si nécessaire. Essayez de rester proche des définitions, mais adaptez les à cet environnement de test.

Termes et concepts

Après
Marks functions to be run after #describe, #context, and #it. It uses a single queue so all functions will be run in the correct sequence.
Part of the teardown of #test fixture.
Also known as teardown.
AprèsTout
Marks functions similar to #after, except it is run only once. Strictly speaking this function is not necessary as code can be added inline. It uses a single queue so all functions will be run in the correct sequence. It uses 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.
Part of the teardown of #test fixture.
Après
An alternate to #after that is only run if the test #throws an #exception. If an exception is thrown, and there is an around function registered, then no after function will be run.
Part of the teardown of #test fixture.
Assertion
Test that focuses on the actual code, and assertions about that code, and their falsy #conditions.
Part of the verification of #test fixture.
Avant
Marks functions to be run before #describe, #context, and #it. It use a single queue so all functions will be run in the correct sequence.
Part of the setup of #test fixture.
Also known as setup.
AvantTout
Marks functions similar to #before, except it is run only once. Strictly speaking this function is not necessary as code can be added inline. It uses a single queue so all functions will be run in the correct sequence. It uses 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.
Part of the setup of #test fixture.
Carp
A #spy that adds a message to stack without exiting the test, printing the caller's name and its arguments. Partly emulating the carp() function from Perl.
Cluck
A #spy like #carp, but also prints a stack trace starting one level up. Partly emulating the cluck() function from Perl.
Condition
A logical expression that can be evaluated as True or False, e.g., A>B.
Part of the #assertion.
Confession
A #spy like #croak, but also prints a stack trace starting one level up. Partly emulating the confess() function from Perl.
Contexte
Marks functions used as examples, but also a function context() itself.
See #example for details.
Intégration continue
Agile approach to software development to minimize the duration and effort during each iteration, and at the same time deliver software suitable for release.
This dual objective requires an integration procedure that is reproducible, usually by automated integration and builds – often multiple times each day, and achieved through extensive testing, version control, team policies, and conventions.
Couverture
The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.
Critères
Decision rules are used to determine whether a test item (function) or feature has passed or failed a given test. In specs it is only used simple pass/fail.
Croak
A #spy like #carp, but also stops the running test (the user provided anonymous function). Partly emulating the croak() function from Perl. Because it throws an exception it will always trigger a stack trace.
Description
Marks functions used as examples, but also a function describe() itself. See #example for details.
Conception
Also known as test design
The process of transforming general test objectives into tangible test conditions and test cases.
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 /doc subpage for the spec page.
Développeur
A person that write code. See #tester
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 /doc subpage for the spec page.
Factice
A necessary minimum implementation of functionality that is only necessary to make some other implementation available for use. Such objects are usually created inside the tests, and lifespan is limited to the tests. A dummy is a type of #test double.
Durée
Time elapsed while executing a test, test run, or the entire test execution of a build or release pipeline. Scribunto uses cpuLimit to limit total duration of a test run.
Exemples
The levels in the #describe, #context, and #it ladder. The name and level are a bit arbitrary as they all have nearly 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.
Attendus
Tests that focus on the provided objects and examples, and their truthy states.
Échec
A test is deemed to fail if its actual result does not match its expected result.
Feint
A simpler alternate implementation of functionality that otherwise would be too heavy or difficult to implement or not feasible to use. Such objects are usually created inside the tests, lifespan is limited to the tests and enhances the performance of tests. A fake is a type of #test double.
Fonctionnalité
An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability, or design constraints).
Fixation
The function defining the test is the test fixture and a frame without a test fixture will be skipped.
Bon
See #pass for details.
Exploite
A test environment comprised of stubs and drivers needed to execute a test.
Ceci
Marks functions used as examples, but also a function it() itself. See #example for details.
Maquette
A simulated object that acts as a strictly controlled replacement for a real object and is used to verify the interaction between the modules and services that is compared with the expectation value which corresponds to the number of times the modules and services must interact with each other while a test is running. A mock is a type of #test double.
Suradaptation
Happens when too tight couplings between the test and source code exist. Usually this happens when tests use spies to verify internal data structures in source code.
Passe
A test is deemed to pass if its actual result matches its expected result.
En attente
A frame marked with #skip or #todo will be in a pending final state. This state is an override of #pass ("ok") and #fail ("not ok") and makes it possible to code and test with less noise.
Retourne
The outermost zero-level that encapsulates the test results and returns them in a formatted fashion.
Installation
See #before for details.
Passer
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.
Spécification
A type of testing to ensure we build the thing right, usually by writing some kind of unit tests, but can also be more high level.
Espion
Functions that can be registered on other functions, or injected into code to report or alter internal states. Spies are one of #carp, #cluck, #croak, and #confess. Spying on public calls made before the module is available to the testing regime will not be possible. A spy is a type of #test double.
Étape
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.
Ébauche
Simulated placeholders for real code, used to isolate and test specific system parts by excluding certain dependencies. A stub is a type of #test double.
Sujet
The object under test. It can be explicitly set or set as part of the #examples. It is passed on to #expect.
Démontage
See #after for details.
Test
An activity to verify the proper operation of a system, given that it is executed under specific conditions, and with observed and recorded results. Consists of one or more #test cases.
Cas de test
A set of input values, execution preconditions, expected results, and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. Can also include documentation for how to run the test case.
Doublons de test
Code replacing pieces of code that are not tested, and should return only known values.
Élément de test
The individual element to be tested. Usually, it is one test object and many test items.
Testeur
A skilled user who is involved in the testing of a component or system. See #developer
Lance
The test code can run into a statement that either can't be executed and thus "throws" an exception or explicitly "throw" an exception at that point. When the code throws an exception further execution is stopped and a report is initiated.
À faire
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 continue, but the final state is set to pending anyhow.

Liens externes

Merci d’essayer d’adhérer aux termes communs de l’International Software Testing Qualifications Board (ISTQB), de l’American Software Testing Qualifications Board (ASTQB) et de l’Information Technology Infrastructure Library (ITIL).