With larger, more complex applications and infrastructure, more intricate CI pipelines with various steps and stages and so on, the need to have your Cypress tests run on different environments often arises.
Typically, our integration tests run in a dedicated build step once we’ve deployed to Development and that’s that for tests that run on the pipeline. As the build goes through the subsequent environments (Staging -> Pre-Prod -> Prod etc.) we carry out other forms of release testing on that particular environment. Great. However, when a bug appears to have made it to the Staging environment for example, or…
An issue most of us have seen!
Some web-elements are dynamically generated as a result of a previous action. For example, selecting a check-box in a web-form might populate the UI with another panel or field. Often these elements similarly have a dynamically generated Class or Attribute name and no static ID or Class we can reference when running cy.get(). A great example of this can be found over at Amazon, inspecting the DOM there should give you an idea of just how dynamic everything is. The following is a div Amazon use which contains a list of products:
File uploads are a hit and miss with Cypress. There are no built-in commands that handle file uploads and you typically need to get creative with jquery events or install a node package such as cypress-file-upload to try and get your files uploaded through the frontend. In this post, I’ll be demonstrating how I’ve tackled this and what I use to test endpoints with file uploads.
As we query the various endpoints as part of an API we are typically given a response. This response follows a specified schema set by the developers when they built the API and is traditionally returned as JSON. There are different schemas for different endpoints and even schemas based on the status of the API call. As QA, we could/should go the extra distance and verify that the schema returned is valid.
Cypress has a marvelous post that you can read through on schema validation using JSON Schemas here
Software Developer in Test with a biased and love for E2E API Testing