<img src="https://images.unsplash.com/photo-1488590528505-98d2b5aba04b?ixlib=rb-1.2.1&#x26;ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&#x26;auto=format&#x26;fit=crop&#x26;w=1770&#x26;q=80" alt="Web browser">
Recently at work, I had the task of automating a journey of performing an action on one domain and verifying the result on another domain.
Turns out this was more challenging than I previously thought.
I don’t have too much experience with Cypress so this gave me an excellent opportunity to dive in and learn more about it.
So for this blog post, I wanted to share what I’ve learnt about Cypress this month.
<h2>Yielding with ‘then’</h2>
So here’s an interesting one to start with. As described above, I needed to verify an action done on one domain (X) on another (Y). To do this, I needed to login to website Y by using a value in a cookie from website X. Turns out this was a good learning experience in understanding the limitations and trade offs of using Cypress.
My original plan was to just use the <a href="https://example.cypress.io/commands/cookies#getCookie">get cookie</a> command, get the value from the header and assign it to a variable so I can use it in a visit command. Should be straightforward right?
Not so much due to several reasons. One of them being that the Cypress API is <a href="https://docs.cypress.io/guides/core-concepts/variables-and-aliases#Return-Values">asynchronous</a>. You can’t use the return values of Cypress commands or assign them to a variable.
This is annoying at first, and a bit confusing to get your head around. But if you think about it, modern web applications aren’t synchronous.
To get around this, I decided to take a look at yielding Cypress commands with the ‘then’ statement, like so:
<pre><code>cy.getCookies().then((cookies) => {
	cy.log(cookies[0]['thing']
	cy.visit('www.whatever.com/' + cookies[0]['thing']
})
</code></pre>
In theory, this should access the value held within the cookie and concatenate it to to the end of the visit command.
But this lead to another issue that had me and my colleague scratching our heads for a bit…
<h2>The mystery restart</h2>
Whenever Cypress would reach the visit command inside the ‘then’ statement, Cypress would restart itself. There would be no error printed to the console of the browser which made things a little difficult to find out what was going on.
It wouldn’t restart the whole test, only the current ‘it’ statement. It sounds crazy, but I assure you, it’s true! One of my colleagues saw it happen as well. So we decided to investigate.
At first we looked at the possibility that the cookie value needed to be encoded properly to be used in a URL. So we decided to use the JavaScript function <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURI">encodeURI</a> to see if that made a difference. Sadly it didn’t, Cypress would still restart itself.
My colleague found a <a href="https://github.com/cypress-io/cypress/issues/3454">GitHub</a> issue about the same behaviour of Cypress restarting. This was opened in 2019 and the last comment was a year ago, so it’s an issue that is still affecting Cypress today.
So we decided to have a rethink and we were able to make some progress but we soon hit another problem; Cypress doesn’t support navigating to different domains within the same test.
This is described in the Cypress <a href="https://docs.cypress.io/guides/references/trade-offs#Same-origin">documentation</a> as a trade off. So if you had a test that was visiting <code>abc.com</code> you cannot change to <code>xyz.com</code>.
In the end, the test was then split into two different tests to get around it. Now we know for next time!
<h2>DIY environment toggles</h2>
One thing I learnt is making your own toggles that affect your tests in Cypress.
I saw that the console was printing out a ton of XHR requests in a test and it made reading what was going on in the test difficult. So I decided to do some research of how I could turn off logging this information.
After doing a quick <a href="https://gist.github.com/simenbrekken/3d2248f9e50c1143bf9dbe02e67f5399">search</a>, you can! But if you wanted to enable this logging again, you’d have to remove the code, which I felt wasn’t great. I decided to take a look at making this into a toggle of some sorts.
Turns out you can! This lead me down the road of <a href="https://docs.cypress.io/guides/guides/environment-variables#Setting">environment variables</a> in Cypress. With this in mind, I decided to create an environment variable for hiding XHR requests.
So, here is the code that lives in the <code>index.js</code> file (under the support folder):
<pre><code>if (Cypress.config('hideXHR')) {
 const app = window.top;

 if (!app.document.head.querySelector('[data-hide-command-log-request]')) {
 const style = app.document.createElement('style');
 style.innerHTML =
 '.command-name-request, .command-name-xhr { display: none }';
 style.setAttribute('data-hide-command-log-request', '');

 app.document.head.appendChild(style);
 }
}
</code></pre>
And here is the code for the <code>cypress.json</code> file:
<pre><code>{
	"hideXHR": true
}
</code></pre>
Now you can simply toggle it to either true or false depending if you want to see XHR logging or not! (And it turns out someone had the same <a href="https://dev.to/samelawrence/muting-noisy-xhr-logs-in-cypress-4495">thought</a> as I did!)
I also decided to create an environment variable for ignoring uncaught exceptions (as the application I was working with would throw an uncaught exception and not provide a stack trace).
This was done by taking the code in the Cypress <a href="https://docs.cypress.io/api/events/catalog-of-events#Uncaught-Exceptions">documentation</a>, wrapping it in an if statement and updating the <code>cypress.json</code> file.
<h2>Wrestling with Wait (and timeouts)</h2>
Cypress is quite clever that it will wait until the DOM has been loaded before looking for elements. It’s part of the <a href="https://docs.cypress.io/guides/core-concepts/retry-ability">retry-ability</a> of Cypress.
However, in the application that I was working with, Cypress assumed that the DOM had been fully loaded. So in some cases, the test would fail because the element didn’t exist yet.
At first, I would use the <a href="https://docs.cypress.io/api/commands/wait#Syntax">wait</a> but my colleague showed me something else, changing the timeout value.
Initially, Cypress has a default timeout of 4 seconds, but this value can be changed, like so:
<pre><code>cy.get('.css-class', { timeout: 10000 })
</code></pre>
This command now has a timeout of 10 seconds. I find this to be better than using wait commands.
<h2>Cypress Studio is useful in capturing tricky elements</h2>
There was an element I was having trouble accessing, where it could disappear if you click away from it. So trying to access the element with the development tools or Cypress itself wasn’t possible.
So I turned to <a href="https://docs.cypress.io/guides/core-concepts/cypress-studio#Overview">Cypress Studio</a> so I could record the steps of capturing this particular element.
And Cypress Studio caught exactly what I needed. It’s quite powerful of how it will write the steps of what was recorded to your JavaScript file so you can take a look at what was done.
Although it’s an experimental feature, it’s still worth giving it a spin if you’re struggling with an element which has a behaviour that works against you.
You can enable it by updating your <code>cypress.json</code> file with the following:
<pre><code>{
 "experimentalStudio": true
}
</code></pre>
<h2>Having patience with Jenkins</h2>
A problem that I didn’t think that I’d encounter is with <a href="https://www.jenkins.io/">Jenkins</a>. My cypress tests would work fine locally but wouldn’t work when a Jenkins job would run them.
Curious, I looked at the screenshots that were captured and found that the reason for the test failing is because it couldn’t find the element, and it seemed that part of the page was still loading (this was mentioned before as Cypress thought that the DOM had loaded)
As an experiment, I decided to increase the timeout value to 50 seconds and sure enough, it passed. So I had to extend all the existing timeouts to much larger values.
Maybe the cause of this was due to the VM that Jenkins uses is significantly slower than my work machine.
<h2>Code reviews are helpful in finding areas where you can improve</h2>
I’ve never really ben part of code reviews before, as I previously worked as a manual software tester. So this was a good way for me to learn from others and gain confidence in writing better tests next time.
<h2>Until next time…</h2>
Hope you enjoyed reading this post about Cypress! Who knows, maybe I’ll do a follow up post next month about more things I’ve learnt about Cypress.

From creating environment variables to a mystery restart.

What I’ve learnt about Cypress this month (as a newcomer) 🤖 

When it comes to testing, I've had plenty of experience (I mean, seven years of experience) and if there's one thing I stand by it's my view on automation. Automation, in many ways, is the future of testing. Automation helps free time for QA Engineers to explore issues and other work. Plus, the journey to automate your application provides a great opportunity to advance your career. Plus, with applications continuing to grow in size and complexity, automation is key in tackling applications which would normally take a long time to manually test during each regression check.
Web automation isn't new, there are other solutions to this problem such as <a href="https://www.selenium.dev/">selenium</a> - but I've found selenium troublesome to use. From configuring web drivers to wrestling with syntax, waiting for pages to load, selenium might not be the best automation tool out there. So, <a href="https://www.cypress.io/">Cypress</a> has changed that. With features such as time travel, automatic waiting and being able to configure different viewports really easily - Cypress is quickly becoming a popular tool for web automation.
With it's easy to use API, good documentation (seriously, the <a href="https://example.cypress.io/">kitchen sink</a> is a really good source to practice cypress), getting started with Cypress is really easy. And it comes with support for different browsers out of the box! Tests for Cypress are written in JavaScript and having some knowledge of the language can be quite useful (as I'll go into detail).
A hidden benefit of using Cypress is that since the tests are written in JS, you can use your favourite IDE to write the tests. I prefer to use Visual Studio Code myself as I can the terminal integrated into the IDE and have Cypress running from it.
One thing I have noticed about Cypress is just how fast it is to set up and go. Installing Cypress is done via NPM and be installed anywhere on your machine and it's quite fast on starting up. Plus, if you make a change to a test you're working on, Cypress will automatically reload!
Let's talk about writing tests for Cypress. Something that you'll be doing most of your time while using Cypress. As Cypress is built on top of Mocha and Chai, writing tests supports the use of BDD and TDD (but I prefer BDD) so organising your tests is relatively easy. I've got a working example of a Cypress test looking at the kitchen sink <a href="https://github.com/JB-26/cypress-practice">here</a> if you want to take a look.
Let's jump in!
<pre><code>//create array of viewports for test
const sizes = ["iphone-xr", "ipad-2", "macbook-13"];

//generate a random number between 1 and 10
let randInt = Math.floor((Math.random() * 10) + 1);
//print to console
console.log(randInt);
</code></pre>
Cypress has a <a href="https://docs.cypress.io/api/commands/viewport">viewport</a> command that allows you to adjust the height and width of the browser window. You could enter your own values or use a set of preselected ones. In this case, I created an array and stored the string values of the stored pre-sets.
Oh, and I wanted to generate a random number so I can use it later.
So when we come to run the tests...
<pre><code>sizes.forEach((size) => {
</code></pre>
Cypress will iterate through the array, looping over each viewport for the test. Which is quite handy if you want to check multiple views for a test.
So let's breakdown a test:
<pre><code>describe("Navigate to my site!", () => {
 sizes.forEach((size) => {
 //using string interpolation to display the name of device
 it(`Go to kitchen sink and visit "type" section on ${size}`, () => {
 //set viewport
 cy.viewport(size);
 //visit website
 //cy.pause();
 cy.visit("");

 //click the link
 //cy.pause();
 cy.contains("type").click();

 //get an input and check if its empty
 cy.get(".action-email").should("be.empty");

 //get an input and type into it (then verify)
 cy.get(".action-email")
 .type("fake@email.com")
 .should("have.value", "fake@email.com");

 //check if disabled text area is disabled
 cy.get(".action-disabled").should("be.disabled");
 });
</code></pre>
We describe first of what the test will involve, and then use it to breakdown each step. In the example above, Cypress will perform the following:
<ul>
<li>Set the viewport from the sizes array.</li>
<li>Visit a website (which is configured in the cypress.json file - under the 'baseURL' property)</li>
<li>Click on a link which contains the text "type"</li>
<li>Get the input using a class called '.action-email' and check that the form is empty.</li>
<li>Get the input (same class) and type "fake@email.com". Check to make sure the value of the field is "fake@email.com"</li>
<li>Check if the field using the class ".action-disabled" and ensure it is disabled.</li>
</ul>
This test is executed in the Cypress test runner - which has a number of great features:
<ul>
<li>Screenshot and video recording</li>
<li>Time travel (view previous states in the test runner)</li>
<li>Before and after screenshots</li>
</ul>
It's all pretty great at how Cypress provides a great level of detail for the tests that are being run.
On top of that, writing the tests themselves is easy to do (if you are familiar with JS). The fact that the actions almost read like a sentence helps with readability.
So what else can you do with Cypress?
Well...
<pre><code> it(`Go to the kitchen sink and visit the navigation section on ${size}`, () => {
 cy.viewport(size);

 cy.visit("");

 cy.contains("reload")
 .click();

 //check the location of the pathname
 cy.location('pathname').should('include', 'navigation');

 //go back one page
 cy.go('back');

 //check the location of the pathname again
 cy.location('pathname').should('not.include', 'navigation');

 cy.contains('title')
 .click();
 
 //check the title of the page
 cy.title().should('include', 'Kitchen Sink')
 cy.title().should('not.include', 'test')
 });
</code></pre>
What this test does is:
<ul>
<li>Visit the website</li>
<li>Click on the reload link</li>
<li>Check the pathname in the URL to include navigation</li>
<li>Go back one page</li>
<li>Make sure that the pathname does not include navigation</li>
<li>Make sure the title includes Kitchen Sink and not test.</li>
</ul>
So you can not only check what's on the page, but the metadata as well.
But this is only a small example of what you can do with Cypress. The <a href="https://docs.cypress.io/guides/references/assertions#Chai">documentation</a> has some great examples of what you can do with Cypress.
Remember the random integer I mentioned above? I decided to use that just to see the random number being entered!
<pre><code>cy.viewport(size);

 cy.visit("");

 //click the link
 //cy.pause();
 cy.contains("type").click();

 //get an input and check if its empty
 cy.get(".action-email").should("be.empty");

 //get an input and type into it (then verify)
 cy.get(".action-email")
 //use the random integer
 .type(`${randInt}`)
 .should("have.value", `${randInt}`);
</code></pre>
And also, I use string interpolation on the title of the test so the user can see what viwport is being used.
<pre><code>it(`Go to the kitchen sink and visit the navigation section on ${size}`
</code></pre>
It's pretty amazing of just how much JS you can use to enhance your Cypress tests.
It's not just automating testing of sites, it can also make <a href="https://docs.cypress.io/api/commands/request">requests</a> as well (but I think <a href="https://www.postman.com/">Postman</a> or <a href="https://insomnia.rest/">Insomnia</a> would be better suited for the task of testing APIs etc.)
But if you're looking for a tool for web automation, be sure to check out Cypress. They have a strong community on <a href="https://github.com/cypress-io/cypress">GitHub</a> and also have a <a href="https://docs.cypress.io/guides/references/roadmap">roadmap</a> of upcoming features.
Thanks for reading! 👍

Taking a look at some web automation with Cypress

Joshua Blewitt

Posts tagged with JavaScript