DEV Community: Milan Nicic

Cypress-Qase integration

Milan Nicic — Fri, 28 Apr 2023 08:50:06 +0000

As I introduced myself in previous blogs, I will skip that part in this one. As you already saw in the title, theme for this blog will be connecting Cypress to test management tool called Qase. So that on run in Cypress, we create a test run in Qase too!

I will do it from freshly installed cypress project. After installing Cypress, we need to install dependencies cypress-multi-reporters and cypress-qase-reporter.

Now we are ready to add the configuration in order to be able to create test runs in Qase too! In cypress.config.js we need to configuration for cypress-multi-reporters that we installed and for cypress-qase-reporter. Really important part here on the photo below is cypressQaseReporterReporterOptions because you need to setup your API token which you generate in your QASE account, you need to put your projectCode which you can see in the QASE too, basePath is always the same and rootSuiteTitle is in which suite your test cases are located.

So when we setup all this, we are ready to assign values to variables QASE_REPORT to equal 1 and QASE_RUN_NAME to equal whatever we want. In this case I am using Windows and I will do it in Cypress CLI as on photo below

In this example test run will be created in Qase app with the name Cypress-automation-run

So the configuration is done, now we need to go to spec file in Cypress and import qase function as on photo below

Then in our test we call it like this

So the test case with the ID-1 in QASE will be displayed in the Test run when cypress finishes the run, cases that don't have ID in Qase will be created under root rootSuiteTitle > describe section in test > test cases created here

Useful links:
https://app.qase.io/user/api/token
https://github.com/qase-tms/qase-javascript/tree/master/qase-cypress

Optimizing Your Cypress Tests: Tips for Efficient Waiting and Assertion Handling

Milan Nicic — Tue, 21 Mar 2023 12:23:05 +0000

Since I started writing automated tests I always looked for a best practices in terms of waiting. So lets start with basics, we all know there are implicit and explicit waits.

Lets start with implicit wait, for implicit wait in Cypress we have cy.wait() command in which we pass how much miliseconds we want to wait. This is bad approach and if you ask why? Here is the answer, for example if you want some element to appear and sometimes it appears in 2 seconds, sometimes in 3 seconds, sometimes in 5 seconds, you would need to put cy.wait(5000) in order to cover the latest time in which element can appear, but if element appears in 2 seconds, you will still wait 5 seconds no matter what happens. This is why this is a bad approach.

Instead we need to use explicit waits, in Cypress we have multiple options on how to use explicit waits I will count every wait that I use regularly in my tests!

First of all, the one that you will use the most is .should() command that waits for specific state for example this command in photo below will wait for element to be visible and then it will continue the test. Should command will constantly retry to see if element is visible by default 4 seconds, but we can change that in defaultCommandTimeout. This is a good practice!

There is another way to check is element is visible. I am using Cypress helper methods in this link there are all helper methods you can use! Particularly for this scenario I use Cypress.Dom.IsVisible as on photo below. Keep in mind this does exactly the same like in previous image, just another way. I added this just to let you know of different helper methods!

Keep in mind that .click() command in Cypress has built-in retry-ability to find and click on element, so if you have element that appears after few seconds, you don't need to use .should() assertion before actually clicking on element.

Another type of wait that we can use in Cypress is to wait some API request to finish before proceeding with the test. We can do this by using cy.intercept() command as on photo below

cy.wait() will resolve as soon as request is finished.

At the end of this post I want to go back to .should() command, what I want to mention is that with this command you can wait for almost anything, e.g. if list is loading slowly and you want to wait till list has length of 5 you can do that as on photo below

These are explicit waits that I constantly use in my tests, I hope you found this blog useful for your daily work! If you did, please leave a follow on LinkedIn

See you in next blog!
Cheers!

How to handle new window and tab in Cypress and use of cypress-map plugin

Milan Nicic — Fri, 17 Mar 2023 11:48:25 +0000

Introduction

Hello there! My name is Milan, and I'm a test automation engineer. As someone who's passionate about all things automation, I'm thrilled to share some of my insights and experiences with you today, particularly when it comes to using Cypress.

If you're not already familiar with it, Cypress is a powerful test automation tool that's quickly gaining popularity in the industry. As a long-time user of Cypress myself, I've seen firsthand how it can help teams to streamline their testing process, improve their test coverage, and catch bugs earlier in the development cycle.

In this post, I'll be diving into some of the key trends and best practices that are shaping the industry right now, with a focus on how Cypress can help you take your automation game to the next level. Whether you're looking to optimize your test suite, troubleshoot common issues, or simply stay up-to-date with the latest automation tools and technologies, I've got you covered.

How to handle new tabs and browser windows in Cypress

One common challenge in test automation is dealing with new browser tabs or windows that open during a test. For example, if you click on a button that opens a new tab or window, you'll need to be able to switch to that tab or window in order to interact with it. But what we should keep on our mind is that we don't want to automate browser behaviour, we want to automate the actual app.

In the past, I used to search through the web for the best solution in order to be able to automate new tab and window and I will present you what approaches I am currently using when I need to handle one of those.

Lets start with new tab, first of all it depends how the web application has been developed. By that I mean if the button for example has attribute target=_blank or it opens new tab with the window.open method. Based on this we can have 2 approaches, first one is to change the value of target attribute to _self e.g.

Or we can remove the target attribute e.g.

What this does is that link that is inside href attribute is being opened in the same tab instead of being open in a new tab. That way we are able to access elements on the new page.

Now question that probably comes to your mind is, what if the element doesn't have target attribute, how would you automate this scenario?

As I mentioned above, new tab could be triggered by window.open method so the approach in Cypress would be to stub the window.open method and assert that it is being called with proper link e.g.

What this does is it creates a stub function that replaces window.open() method that can be controlled later on during testing. Alias is added too so we can assert the behaviour of stub function.

Cypress-map plugin

First of all, let me take this opportunity to thank Gleb Bahmutov for creating this great plugin!

Cypress-map is really complex plugin and I won't cover all the posibilites it has, but one of them that I often use and that makes me faster doing my daily work I will!

For example, you want to assert some text of list of elements in Cypress so one of the quicker ways that I was using in Cypress was Cypress._.map lodash method e.g.

This is one way of creating a new array of values by mapping each value in the input array through a mapping function.

Though now we can use cypress-map plugin and do the same thing with just one line of code e.g.

For more posibilites of this plugin you can visit https://github.com/bahmutov/cypress-map
I will cover more in the future indeed!

Thank you for reading this post!
Cheers!