Cypress tests organizing (or any e2e/ui tests)
Nowadays cypress is quite a hype technology (I am saying this in Fall 2020, everyone knows how rapidly js world can change ;))
"Cypress is a next generation front end testing tool built for the modern web."
https://docs.cypress.io/guides/overview/why-cypress.html#In-a-nutshel
I had some experience with Behat and other types of tests like unit/integarational, but today I will tell you about e2e.
When I wrote Behat tests I didn't think a lot about how to structure my test cases in a maintainable way. This led me to the antipattern called "Single-Layer Architecture"[1].
Extending such tests quickly becomes a mess and tends to become an ineffective work:
- You can't focus on business logic, you always need to remember low-level details to introduce a new step definition
- Your low-level solutions are often duplicated, and you even don't notice that
- Changing testing framework means rewriting or updating all step definitions!
Fortunately there is an approach which is very easy to follow and which mitigates mentioned issues.
Continuous Integration with Circle CI v2 with Node.js and PHP examples
Second version of Circle CI configuration changed dramatically.
It introduced workflows, and they are used in pipes meaning.
Every workflow can include multiple steps.
Node.js example:
Continuous integration using Travis CI and Behat
This note begins a series of notes on application development and deployment processes. To start with, I will show how you can relatively easily implement a code quality and functionality checking process using the Travis CI service.
The practice of continuously checking the build for defects is called Continuous Integration.
The question of writing tests will not be addressed in this article - it is the subject of another article. It is assumed that you have already set up Behat, and the tests can already be run locally using Selenium.
To begin with, let's check if there are any rule violations in the code. This will allow you to familiarize yourself with and start using Travis CI. If you don't have any tests, I strongly recommend at least checking the code style.
The justification for the importance of code consistency and style can be found in many places, for example, Steve McConnell's "Code Complete", part 7, section 31.