BDDX comes with built-in test scenario templates, useful if you just want to check out how it works (before you obviously write your own tests)
Feature: Display .feature file
User should be able to see the test scenario after selecting the test path.
For example, there is a
userHandling directory with
If user selects the
/userHandling path in the config file all tests should be displayed sequentially one after another.
Scenario: User wants to run login.feature tests from the /userHandling path Given /userHandling path exists And login.feature exists And there is a tool to display test content When user interacts with this tool Then test login.feature should be displayed And after passing or failing, the next test from the selected path should be displayed And if this is the last test or there was only a single test in the path, program should quit But If path does not exist or there is a typo, then the proper error message should be displayed
Pass or fail test
Feature: Verification of a functionality through a test
User can decide if the functionality passed the test or not, by asking if everything is ok. The first version can be based on the switch/if instruction, when the question is displayed and everything is ok user presses 1, but if something is wrong then user presses 2 and write what's wrong.
Scenario: User wants to test the register functionality via the register.feature test which is in the /userHandling path, but one of the register inputs is broken Given register functionality exists And register.feature file exists in the selected path /userHandling which also exists And there is a tool to approve or reject the functionality test results And this tool has the functionality to ask if everything is ok And this tool has the functionality to ask for the rejection reason and save it to the selected output file if something is wrong And the contents of the test can be displayed correctly When user interacts with this tool by testing the functionality for errors Then user should be able to reject this test's result And there should be a place to write why the test result is rejected And the rejection reason should be saved in the output file But if the functionality is ok, then user can decide the test was passed And information about the passed test should be saved in the output file