At the moment the framework has configuration for both gherkin and page objects applied to the standard Codeceptjs setup. One simple E2E test has been setup using bdd and the codecept generic dsl to compare them. The driver being used is Selenium Webdriver, default is not headless when running locally (Chrome being used).
Run all End to End feature tests without a browser
HEADLESS=true npx codeceptjs run --features --reporter mocha-multi --grep "E2E"
Run all End to End feature tests with a browser
npx codeceptjs run --features --reporter mocha-multi --grep "E2E"
The project is using the codecept gherkin snippet template in order to manage and maintain a user readable test format in a standardised approach. The language used attempts to stick to D-R-Y principles as much as possible to limit the number of steps, encourage reuse and low maintenance overhead.
This means identify simple user action phrases so that steps and the contaning step definition files are kept to a minimum.
To enhance this low maintenance overhead objective, the page object model snippet plugin for codeceptjs has also been added.
- Feature files sit under the features folder within their own sub-folder.
- Steps are under step_definitions folder within their own sub-folder.
- Reporting is produced using mochawesome and outputs to functional_output.
- Page Objects can be found under pages
- All configuration is stored in codecept.conf.js
- Pending tag used to skip tests
├── features
│ └── access
│ └── access.feature
├── functional-output
│ |── assets
│ |── mochawesome.html
│ |── mochawesome.json
│ └── console.log
├── pages
│ └── login_page.js
├── step_definitions
│ └── access
│ └── manage_access_steps.js
└── codecept.conf.js
We are using the resemble helper to provide a simple visual check between a base image and the current screenshot taken during test execution, any differences will be stored (i.e. the build will not fail, but the differences can be checked post execution)