Sharing our challenges, mistakes, hacks, successes, opinions and news
A single Cypress test might be fast, but if you wait for an entire large test run to finish, you might as well watch the paint dry.
Netlify became a popular Continuous Delivery (CD) and hosting solution for a lot of organizations due to its simplicity and power. Pick your repository, click "Deploy site" ... and the site magically appears.
Cypress makes it incredibly easy to read their code. Even people that don’t work with Cypress here at Slido can easily understand what is going on in the test code...
This blog post shows how to control native <select> HTML elements from Cypress tests. We will also look at how to work with a very popular wrapper library called Select2, that supplants the native <select> elements with an additional HTML markup.
Let's take an application that has an <input type="color"> element. When the user picks a new color, the application changes a CSS variable which controls the background color. In action, it looks like this...
Cypress as a company represents a lot of things I love about tech—the Test Runner is free and open source, we’re a distributed team, and I get to work with some incredibly smart people to make it easier for people to write and test better software.
This blog post aims to convince my fellow QA engineers to learn and use Cypress.
Your application might be a layered cake of historical data. Often old records are missing pieces because at first the web application never asked for them, or never validated them.
Why is testing a web application so hard? Why generic browser automation tools do not fit well the UI/E2E testing needs? Why does Cypress outstand? A generic features comparison is not enough to understand what are the main UI Testing pains and how Cypress removes them.
