LivingDoc is a testing tool and framework that supports teams in implementing advanced agile testing practices such as Acceptance Test-Driven Development (ATDD), Spec-by-Example and Behavior-Driven Development (BDD). LivingDoc’s primary focus is to facilitate the cooperation of people in the roles of domain expert, developer and tester, the three amigos in BDD.
- Domain Expert
-
Someone supporting a development team with their deep knowledge of the domain in which development of the SuT is taking place.
- Developer
-
As part of an agile development team a developer creates and tests the SuT.
- Tester
-
Someone providing their expertise in agile software testing to a development team.
- Decision Table
-
A table where each row represents a Test Case. A column can contain either a Test Input or an Expectation.
- Example
-
A description of the behavior of the System under Test, which can be automatically verified by LivingDoc. Scenario and Decision Table are examples.
- Executable Document
-
A document describing the System under Test. It contains zero or more Examples.
- Expectation
-
A value that is passed to the Fixture to determine the outcome of a Test Case.
- Fixture
-
Coded by a developer, a fixture is used to execute a Test Case. The fixture maps Test Inputs to a series of interactions with the System under Test and evaluates Expectations.
- Report
-
A meaningful composition of an Document and the Status of its execution.
- Repository
-
This is were Executable Documents are stored.
- Scenario
-
An Example describing a single Test Case as a sequence of Steps.
- Scenario Step
-
A single step of a Scenario represented as a sentence containing either one or more Test Inputs or one or more Expectations.
- Status
-
Calculated by LivingDoc for each Test Case when executing a Document. A status is always one of: Success, Failure, Error or Skipped.
- System under Test (SuT)
-
The system against which Test Cases are executed.
- Test Case
-
The smallest independently executable part of an Executable Document. A test case has to define one or more Expectations. If all expectations are met, the test case succeeds, otherwise it fails.
- TestData
-
Same as Example. This is only used in code as "example" is not very expressive there.
- Test Input
-
A value that is passed to the Fixture to set up an interaction with the System under Test.
- Type Converter
-
Referenced by a Fixture, a type converter takes Test Inputs and maps them to types in the test domain (e.g. converts the string
"5 €"toCurrency(Type.EURO, 5)).