Cypress Cucumber E2E Testing Framework project represents a starting point for writing tests in Cypress with Cucumber.
Provided tests are based on examples how to define and use utility functions, explicit wait for some element, usage of faker for generating random data and possible solutions for organizing tests using separated files with locators of the elements.
- Install Visual Studio Code
- Recommended extensions in Visual Studio Code:
- Install Node JS
- Clone the repository to your local system
- Open the project in Visual Studio Code and open the terminal
- Make sure the path to the project is correct
<local_path>\cypress-cucumber-e2e-tests
- Make sure the path to the project is correct
- In the terminal, execute the following command:
npm install- The command will install all found in the package.json
Open the terminal inside <local_path>\cypress-cucumber-e2e-tests and use the following commands to:
-
Open the Cypress UI to execute test cases against default environment:
npx cypress open -
Execute all test cases without opening the Cypress UI against default environment:
npx cypress run -
Environment variables:
ENV, which can have valueprod/local/docker/kube/kubeLocal, depending on which environment you would like to execute your tests (if not defined,prodwill be used by default)produseshttps://automationintesting.onlineas app URLlocaluseshttp://localhostas app URLkubeLocaluseshttp://kube.localas app URLdockeruseshttp://rbp-proxyas app URLkubeuseshttp://rbp-proxy.restful-booker-platformas app URL
TAGS, which can be any of available tags set in Cucumber features. If not set all scenarios will be executed. Tag expression is an infix boolean expression, some examples:@sanity- Scenarios tagged with@sanitywill be filtered@management and not @room-management- Scenarios tagged with@managementthat are not also tagged with@room-managementwill be filtered@management and @room-management- Scenarios tagged with both@managementand@room-managementwill be filtered@booking or @contact- Scenarios tagged with either@bookingor@contactwill be filtered(@booking or @contact) and (not @bug)- Scenarios tagged with either@bookingor@contactthat are not also tagged with@bugwill be filtered
Example of above commands with possible variables:
npx cypress open --env ENV=local- Open Cypress UI to execute tests against Local environmentnpx cypress run --env ENV=prod- Execute All tests without opening the Cypress UI against Production environmentnpx cypress run --spec "**/login.feature" --env ENV=local- Execute Login feature without opening the Cypress UI on Local environmentnpx cypress run --env ENV=prod,TAGS='(@booking or @contact) and (not @bug)'- Execute tests tagged with@bookingor@contactwhich are not also tagged with@bug, without opening the Cypress UI on Production environment
Some of predefined scripts in package.json are doing same thing as commands above:
npm run cy:open:localornpm run cy:open:prod- Open Cypress UI to execute tests against Local or Production environmentnpm run cy:run:localornpm run cy:run:prod- Execute All tests without opening the Cypress UI against Local or Production environment
Before you proceed, you should install Docker Desktop depending on your OS and start it:
As Docker for Desktop is paid software now, instead of it you can set up and start minikube using bellow guides:
After Docker for Desktop, or minikube, has been installed on your machine, open the terminal inside <local_path>\cypress-cucumber-e2e-tests and use the following command:
docker compose -f ./docker-compose-restful-booker.yml up -d
That will start Restful Booker Platform locally.
After everything is up and running you will have Restful Booker Platform available at:
- Docker for Desktop:
http://localhost - minikube:
http://kube.local
Before you proceed, you should set up and start minikube using bellow guides:
After minikube has been properly installed and started on your machine, open the terminal inside <local_path>\cypress-cucumber-e2e-tests and use the following command:
kubectl apply -f .kube/restful-booker-platform.yml
That will start Restful Booker Platform locally.
After everything is up and running you will have Restful Booker Platform available at http://kube.local.
Every feature must only contain scenarios related to that it. When grouping scenarios under one feature make sure that @Background for that feature is common for all scenarios.
If some feature is complex and there are different @Background for group them in multiple feature file.
If you have problems describing feature you can use next template, known as a Feature Injection template:
In order to <meet some goal>
As a <type of stakeholder>
I want <a feature>
By starting with the goal or value that the feature provides, you’re making it explicit to everyone who ever works on this feature why they’re giving up their precious time. You’re also offering people an opportunity to think about other ways that the goal could be met.
Using Given-When-Then in sequence is a great reminder for several great test design ideas. It suggests that pre-conditions and post-conditions need to be identified and separated. It suggests that the purpose of the test should be clearly communicated, and that each scenario should check one and only one thing. When there is only one action under test, people are forced to look beyond the mechanics of test execution and really identify a clear purpose.
When used correctly, Given-When-Then helps teams design specifications and checks that are easy to understand and maintain. As tests will be focused on one particular action, they will be less brittle and easier to diagnose and troubleshoot. When the parameters and expectations are clearly separated, it’s easier to evaluate if we need to add more examples, and discover missing cases.
To prevents most of accidental misuse of Given-When-Then use:
- Write Given in Past tense as Passive sentences - these statements are describing preconditions and parameters (values rather than actions)
- Write When in Present tense as Active sentences - these statements are describing action under test
- Write Then in Future tense as Passive sentences - these statements are describing post-conditions and expectations (values rather than actions)
Make sure that there is only one When statement for each scenario.
Also make sure that there are no and conjunctions in sentences. If there is, it must be split into separate step.
- To match Gherkin Scenario Step text Cucumber Expression are used
- When writing Cucumber Expressions matchers always make sure that at least similar words and plurals are covered and will be matched by using:
Sorry-Cypress is an open-source, self-hosted alternative to paid Cypress Cloud solution, and it enables us to:
- Run Cypress Tests in parallel
- Upload screenshots and videos to your own storage
- Browse test results, failures, screenshots and video recordings
Sorry-Cypress is actually 3 separate applications:
- sorry-cypress-director
- parallelization and coordination of test runs
- 3rd party integration using webhooks
- saving tests results
- generating signed upload URL for saving failed tests screenshots
- sorry-cypress-api
- GraphQL wrapper to query the data stored by sorry-cypress-director
- interface for the sorry-cypress-dashboard
- sorry-cypress-dashboard
- track test runs progress
- browser test results, videos, and failures screenshots
- set projects configuration like WebHooks, Slack, MS Teams and GitHub integration
- create and delete entries (projects, runs)
To run tests using Sorry-Cypress instead of Official Cypress Cloud, Currents-Dev Cypress Cloud cypress-cloud npm package must be used to integrate Cypress with Sorry-Cypress. It does that by setting the environment variable CURRENTS_API_URL to point to our sorry-cypress-director app.
Example of command:
npx cross-env CURRENTS_API_URL=${CYPRESS_DIRECTOR_URL} cypress-cloud run --record --key ${CYPRESS_RECORD_KEY} --parallel --ci-build-id ${CYPRESS_CI_BUILD_ID}
Where:
${CYPRESS_DIRECTOR_URL}- sorry-cypress-director url${CYPRESS_RECORD_KEY}- secret record key, sorry-cypress-director only allows test results with know, predefined, record keys${CYPRESS_CI_BUILD_ID}- unique build identifier used by Sorry-Cypress to distinguish cypress test runs one from another
To be able to run tests using Sorry Cypress, it must be hosted somewhere.
Hosting Sorry Cypress on AWS is the easiest way to get publicly accessible instance of Sorry Cypress, of course there are other options to host in on Google Cloud Platform, Microsoft Azure, Heroku, Kubernetes or Docker. More on different implementations can be found in Sorry Cypress Docs.
Guides on how to set up Sorry-Cypress Hosting:
Guides on how to execute E2E Cypress Cucumber Tests using CI/CD Tools:
![@dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=64&v=4){kind=small}