An independent repository providing control of Nightwatch by exposing it as chainable promise based API. Therefore making it possible to use with any test runner. Also, one interesting use of it demonstrated by the author is using cucumber as test runner. Its explanation is available here and code is available here
An other e2e testing tool that provides BDD-style syntax. Can be a replacement of Nightwatch. Some interesting concepts in Codecept
- Provides a bit different test components, e.g. actors, pageobjects, page fragments
- Exposes API to perform some Web API (REST/GraphQL) requests in tests to perform data generation. https://codecept.io/data
- Datadriven possible
Documentation available here and a sample project available here and here
Some boilerplate projects are available here
A javascript based test automation framework that was developed and made public by Facebook people. It was based on (jasmine)[https://jasmine.github.io/], another BDD development framework.
The key features of JEST include
- Provides required tools out of the box for most Javascript Projects
- Use of snapshots to track large objects with ease (Snapshot Testing)
- Tests are run in parallel
- Readily available mocks, timer mocks, manual mocks and ES6 class mocks
- Run browser tests with puppeteer in multiple ways as described here
- DOM manipulation without browser using jsdom as described here
Here is a sample project and its tutorial
- You can almost achieve all these with mocha using different libraries like sinon, istanbul, enzyme, karma, mocha-snapshots, etc
- On the other hand you can use Nightwatch with Jest. Also, you might have to replace supertest with frisby for api testing.
A complete e2e framework that is different because it does not require selenium or/any webdriver. It applies in-browser-testing and gives an interesting experience by combinning multiple libraries in a single frameworks. Documentation is very interesting and detailed. Including limitations, differences, etc
- https://docs.cypress.io/guides/overview/why-cypress.html#In-a-nutshell
- https://docs.cypress.io/guides/overview/key-differences.html#Architecture
- https://docs.cypress.io/guides/core-concepts/writing-and-organizing-tests.html#Folder-Structure
- https://docs.cypress.io/guides/core-concepts/interacting-with-elements.html
- https://docs.cypress.io/guides/core-concepts/interacting-with-elements.html
- You can stub out backend by handling network traffic
- List of tools bundled together
- Some limitations and tradeoff
They also provide a dashboard service for maintaining recorded tests and support running in CI/CD pipelines
A sample project is available here
A nodejs library to control headless chrome/chromium browser
- Can be used with mocha with the use of mocha-headless-chrome or with jest
- Can be used for different testing including service worker caching, lazy loading, speech, side-by-side page loads, performance monitoring
Current api documentation available here, v1.20.0
$env:URL = "https://jestjs.io/en/"
node .\code_coverage.js
Here is an interesting set of demos where its being used to do big and bold things
Some links to interesting examples, projects and libraries are provided here
While selecting for framework:
-
We need to understand the scope of automation project
- Do you need it for unit, integration, api, e2e or just one
- Will this framework be used across different projects developed in different tech stacks (e.g an UI automation solution required for different applications developed in the company)
- Do we need more generic coverage from test automation or we need something specific (e.g. test across different browsers or testing with chrome in enough. Or do we need to test something specific like service worker caching)
-
We also need to understand the team capabilities and interests
- Can the team work with more flexible and custom configured framework and need to get started with easy-to-use pre-configured framework
- Who will be the main contributors in the framework (i.e. Mostly worked by people with less programming skills or developers will also be using this framework)
- Who will be the end users of the frameworks (developers, QA, business people, etc)
- Which frameworks are already used in the team (e.g. jest is used in unit testing then better to use jest for e2e testing too. Specially if the repository is going to be the same)
-
We also need to understand the health, life and community of the framework/projects
- How big the community is
- How well and detailed documentation we have
- How many contributors we have
- How frequent updates and feature releases are made
- How the core team responses to reported issues and enhancement requests
-
Key features that it should include
- Test runner (support for multiple test runners)
- Data manager
- Test reporter (multiple reporters)
- POM is good to have
- pre/post hooks
- async/await support
- Advanced configuration options
- Parallel execution
- Allow integration with cloud hosting solutions
- Easily usable in CI/CD pipelines