the name or a short description of the Feature
the metadata of the Feature
Define all Stories that belong to this Feature in the body of this function.
Given describes an initial state of a Story.
To join multiple initial states sequentially, you can either chain them together by appending .And to the end of
this function or you can nest another Given inside the bodyFunc to express diverging "Story lines".
Once you finished describing all initial states, you can invoke a state change by calling When inside the
bodyFunc of this Given function.
To validate an initial state with acceptance criteria, use Then inside the bodyFunc of Given.
a short description of an initial state
Use the body of this function to define acceptance criteria, nested initial states or state changes.
A Story describes functional requirements of the tested application as a series of application states and state changes triggered by a user or a system. It contains acceptance criteria that validate the state following a state change to check if the functional requirements are met.
Wdio-workflo evaluates all acceptance criteria defined within a Story and sets their result status accordingly.
States, state changes and acceptance criteria can be implemented using the following functions:
Given to describe the initial stateWhen for state changesThen to define acceptance criteriaa unique id that identifies a Story (1.1, 2.4.5 etc...)
the name or a short description of the Story
the metadata of the Story
Define all states, state changes and acceptance criteria of a Story in the body of this function.
Then represents an acceptance criteria that validates an application state to check if a functional requirement was fulfilled.
An acceptance criteria needs to be uniquely identifiable by a combination of its surrounding Story's id and its
own id (eg. 2.4.5 [1], 2.4.5 [2], 1.1 [1]). The resulting id can be used to reference an acceptance criteria
in a testcase's validate function.
Wdio-workflo evaluates all validations defined inside testcases that reference an acceptance criteria and sets the result of the acceptance criteria accordingly:
the id of an acceptance criteria which must be unique within its surrounding Story
a short description of the expected state under validation
When describes a state change inside a Story that is triggered either by a user or by a system.
To join multiple state changes sequentially, you can either chain them together by appending .And to the end of
this function or you can nest another When inside the bodyFunc to express diverging "Story lines".
To validate the state following a state change with acceptance criteria, use Then inside the bodyFunc of When.
a short description of who did what to trigger a state change
Use the body of this function to define acceptance criteria or nested state changes.
This function provides expectation matchers for PageElements or ValuePageElements.
All template type parameters can be inferred automatically.
an instance of PageElement or an instance of ValuePageElement
the expectation matchers for PageElement or ValuePageElement
This function provides expectation matchers for PageElementGroups or ValuePageElementGroups.
All template type parameters can be inferred automatically.
an instance of PageElementGroup or an instance of ValuePageElementGroup
the expectation matchers for PageElementGroup or ValuePageElementGroup
This function provides expectation matchers for PageElementLists or ValuePageElementLists.
All template type parameters can be inferred automatically.
an instance of PageElementList or an instance of ValuePageElementList
the expectation matchers for PageElementList or ValuePageElementList
This function provides expectation matchers for PageElementMaps or ValuePageElementMaps.
All template type parameters can be inferred automatically.
an instance of PageElementMap or an instance of ValuePageElementMap
the expectation matchers for PageElementMap or ValuePageElementMap
This function provides expectation matchers for Pages.
All template type parameters can be inferred automatically.
the expectation matchers for PageElement or ValuePageElement
If one or more Features in a scope (usually a .spec.ts file) are marked as "fFeature", the test runner will execute only these Features and ignore all other Features defined in the same scope.
A Feature in wdio-workflo represents a collection of related Stories.
the name or a short description of the Feature
the metadata of the Feature
Define all Stories that belong to this Feature in the body of this function.
If one or more Stories in a Feature are marked as "fStory", the test runner will execute only these Stories and ignore all other Stories defined in the same Feature.
A Story describes functional requirements of the tested application as a series of application states and state changes triggered by a user or a system. It contains acceptance criteria that validate the state following a state change to check if the functional requirements are met.
Wdio-workflo evaluates all acceptance criteria defined within a Story and sets their result status accordingly.
States, state changes and acceptance criteria can be implemented using the following functions:
Given to describe the initial stateWhen for state changesThen to define acceptance criteriaa unique id that identifies a Story (1.1, 2.4.5 etc...)
the name or a short description of the Story
the metadata of the Story
Define all states, state changes and acceptance criteria of a Story in the body of this function.
If one or more acceptance criteria in a Story are marked as "fThen", the test runner will execute only these acceptance criteria and ignore all others defined in the same Story.
Then represents an acceptance criteria that validates an application state to check if a functional requirement was fulfilled.
An acceptance criteria needs to be uniquely identifiable by a combination of its surrounding Story's id and its
own id (eg. 2.4.5 [1], 2.4.5 [2], 1.1 [1]). The resulting id can be used to reference an acceptance criteria
in a testcase's validate function.
Wdio-workflo evaluates all validations defined inside testcases that reference an acceptance criteria and sets the result of the acceptance criteria accordingly:
the id of an acceptance criteria which must be unique within its surrounding Story
a short description of the expected state under validation
If one or more suites in a scope (usually a .tc.ts file) are marked as "fsuite", the test runner will execute only these suites and ignore all others defined in the same scope.
A suite is a collection of related testcases.
the name or a short description of the suite
the metadata of the suite
define all testcases for this suite inside the body of this function
If one or testcases in a suite are marked as "fTestcase", the test runner will execute only testcases and ignore all others defined in the same suite.
A testcase is composed of a sequence of steps.
Each step represents a single or multiple interactions with the tested application and allows you to pass a step callback in order to perform validations of the application state right after the step was performed.
Wdio-workflo evaluates all validations defined within a testcase and sets the testcase status accordingly:
Steps and validations can be implemented using the following functions:
given to establish the initial statewhen to describe changes of the application statevalidate to perform validations of the application state inside a step callbackthe name or a short description of the suite
the metadata of the testcase
define all steps for this testcase inside the body of this function
Returns a unique id by concatenating the passed string and a counter value that is incremented on each invocation of the function with the same passed string.
Pairs of each passed string and the latest value of its respective counter are stored in the file uidStore.json and will be preserved for the next test run. To reset a single counter value, you can edit this file. To reset all counter values, you can delete it.
a string for which to create a unique id
the generated unique id
The given function establishes the initial state of a tested application by executing the passed step.
You can also chain together multiple given statements to create the initial state by appending .and to the end
of this function.
Once you finished establishing the initial state(s), you can trigger a state change by appending a .when step to
the end of the given function/chain.
State change steps can also be chained together sequentially by appending .and to the end of the step chain.
a step that establishes the initial state
A suite is a collection of related testcases.
the name or a short description of the suite
the metadata of the suite
define all testcases for this suite inside the body of this function
A testcase is composed of a sequence of steps strung together in a step chain.
Each step represents a single or multiple interactions with the tested application and allows you to pass a step callback in order to perform validations of the application state right after the step was performed.
Wdio-workflo evaluates all validations defined within a testcase and sets the testcase status accordingly:
Steps and validations can be implemented using the following functions:
given to establish the initial statewhen to describe changes of the application statevalidate to perform validations of the application state inside a step callbackthe name or a short description of the suite
the metadata of the testcase
define all steps for this testcase inside the body of this function
The validate function provides the means to validate an application state.
It MUST BE PLACED INSIDE A STEP CALLBACK, otherwise validations will not function properly.
Validations can reference a single or more acceptance criteria in one or more Stories:
In order for wdio-workflo to know which specs (Features, Stories, acceptance criteria) should be validated by this function, you need to pass a validateObject as first parameter. This object's keys are the ids of the validated Stories (eg."2.4.5") and its values are either a single id (eg. 3) or an ids array (eg. [3, 4, 5]) of acceptance criteria defined within the associated Story.
The result status of a validation is determined by the results of all expectation matchers
(eg. expect(1).toBe(2)) defined within its validationFunc:
an object whose keys represent the ids of Stories to be validated and whose values are either a single id or an array of ids of validated acceptance criteria
Define all expectation matchers that together determine the result of this validation inside the body of this function.
All Features marked as "xFeature" will not be executed by the test runner.
A Feature in wdio-workflo represents a collection of related Stories.
the name or a short description of the Feature
the metadata of the Feature
Define all Stories that belong to this Feature in the body of this function.
All Stories marked as "xStory" will not be executed by the test runner.
A Story describes functional requirements of the tested application as a series of application states and state changes triggered by a user or a system. It contains acceptance criteria that validate the state following a state change to check if the functional requirements are met.
Wdio-workflo evaluates all acceptance criteria defined within a Story and sets their result status accordingly.
States, state changes and acceptance criteria can be implemented using the following functions:
Given to describe the initial stateWhen for state changesThen to define acceptance criteriaa unique id that identifies a Story (1.1, 2.4.5 etc...)
the name or a short description of the Story
the metadata of the Story
Define all states, state changes and acceptance criteria of a Story in the body of this function.
All acceptance criteria marked as "xThen" will not be executed by the test runner.
Then represents an acceptance criteria that validates an application state to check if a functional requirement was fulfilled.
An acceptance criteria needs to be uniquely identifiable by a combination of its surrounding Story's id and its
own id (eg. 2.4.5 [1], 2.4.5 [2], 1.1 [1]). The resulting id can be used to reference an acceptance criteria
in a testcase's validate function.
Wdio-workflo evaluates all validations defined inside testcases that reference an acceptance criteria and sets the result of the acceptance criteria accordingly:
the id of an acceptance criteria which must be unique within its surrounding Story
a short description of the expected state under validation
Returns an instance of XPathBuilder to create XPath expressions using functions instead of writing the whole XPath as a raw string.
Using XPathBuilder can help to reduce the number of errors originating from a wrong usage of the sometimes quite complex syntax of XPath.
the initial XPath selector (eg. "//div", "/span")
an instance of XPathBuilder
All suites marked as "xsuite" will not be executed by the test runner.
A suite is a collection of related testcases.
the name or a short description of the suite
the metadata of the suite
define all testcases for this suite inside the body of this function
All testcases criteria marked as "xtestcase" will not be executed by the test runner.
A testcase is composed of a sequence of steps.
Each step represents a single or multiple interactions with the tested application and allows you to pass a step callback in order to perform validations of the application state right after the step was performed.
Wdio-workflo evaluates all validations defined within a testcase and sets the testcase status accordingly:
Steps and validations can be implemented using the following functions:
given to establish the initial statewhen to describe changes of the application statevalidate to perform validations of the application state inside a step callbackthe name or a short description of the suite
the metadata of the testcase
define all steps for this testcase inside the body of this function
Generated using TypeDoc
A Feature in wdio-workflo represents a collection of related Stories.