Cypress for Dummies 5

Steps Parametrization. The shortcut to greatness.

Hi all, It’s me again with another one of these. This time it will be a quick one. We will take a look on how to parametrize the information we can send from the feature files in order to add variations to our tests.

In my previous article we implemented the gherkin language using Cucumber. This step will take all that a step further.

Parameterizing Test Data: Why it Matters?

Every test scenario is unique, but often, they share a common structure. By parameterizing our test, we can reuse these scenarios with different data sets. This approach not only saves time (both test creation time and execution time) but also enhances the test coverage by checking various permutations of inputs and user interactions.

heads up!

I’m following the login example, which is fairly simple and in this context doesn’t have a lot of added value by logging in with a different user. I’m just saying this so we learn a little bit about testing at the same time that we exercise our coding skills.

Is this a good test to have covered? No. I want you to think about every scenario that you would like to parametrize.

In the event that you have more than one role in you application (imagine you have an admin, and consumer role) and you want to test that both can log in, then it would be a good strategy to implement.

Lets jump right in!

Ok, now I will implement parametrization of the user and the password in the feature file.

This is the test we had.

BTW. I am using the ‘Cucumber (Gherkin) Full Support’ vscode extension to highlight the feature files structure the way it is on the image.

This is the extension.

As I said we have to modify the step on the Feature file:

Ignore the color of the @email.com part, it should not be recognized as a tag. It is a bug of the extension.

And now we need to modify the step to include the parametrization. Cucumber has an easy way to recognize types of data for your parameters, I recommend you check the documentation on Cucumber Expressions if you need any of that. But I will just be using the match all symbols {} equivalent to (.*) in regex. Then modify the function to use those parameters.

Before (left) and After (right ) of our step implementation. Note that the parameters are assigned in order from left to right. So, username is the first one.

Now that we modified this steps, we will run our test to check that everything is working correctly. You should be running your tests every time you make a modification.

Here we see the execution result.

But this is just the starting point, it didn’t change a whole lot. It is the same test we ran before, but with the information in a different place, now lets duplicate this test and we can see where this modification really shines!

Here we see how just by changing the feature file we can run several executions with different data.

Scenario Outlines, the real deal!

Now Cucumber has a Keyword to describe scenarios and run the same test with different data sets. It is called Scenario Outline and it will help us a lot!

Here is the syntax and the execution results.

With scenario outlines, running the same test with different values becomes straightforward. Cypress will iterate over the examples table and execute the scenario for each row, treating them as unique tests. One significant advantage of parameterizing tests is the clarity it brings to test reports. Instead of having multiple tests doing essentially the same thing, you have a single, structured test scenario that clearly shows different test cases.

Friendly Tips for Rockstar Test Parameterization

1. Choose Real-Deal Data: When it comes to picking data for your tests, think like your users. Use parameters that mimic what real folks would do with your app. It’s like putting your app to the test in the real world, but from the comfort of your testing environment. The more relatable your test data, the more you’ll learn about how your app behaves out in the wild.
2. Keep It Simple, Tester: Imagine trying to juggle a dozen balls at once — that’s what overloading your test with parameters feels like. Stick to a sweet spot where you have enough to cover the bases, but not so many that you lose track. A clean, well-organized test is your best friend for easy maintenance and less hair-pulling when debugging.
3. Update, Update, Update: Your app changes, people change, and so should your test data. Keep things fresh and relevant by regularly updating your data sets. It’s like giving your tests a new pair of glasses every now and then, so they can see your app in its current state, all clear and sharp.

Wrapping It Up with a Bow

Who knew parameterizing steps in Cypress could be such a game changer? It’s like giving your tests a superpower — they become more flexible, understandable, and just plain better at checking if your app is doing what it should. Think of it as elevating your testing from just going through the motions to really putting your app through its paces.

Can’t wait to share more Cypress wizardry with you in our next article. We’ll be tackling some even cooler stuff, so stay tuned! Keep on testing, and remember: in the world of Cypress, you’re the one casting the spells! 🧙‍♂️✨