Forem: Ajdin Mustafić

Reload the window if an element is not found — Cypress Automation

Ajdin Mustafić — Wed, 21 Jun 2023 12:06:11 +0000

Cypress is a powerful test automation tool that executes very fast, in my experience, sometimes even too fast… I used a recursive function to reload the window if an element was not propagated on the frontend on time.

Test case: Remove the tag from a mention.

(Test case background: Determ app is a media monitoring tool that tracks brand mentions from all over the internet. One of its features is that a user, for easier sorting of their mentions, can create and add tags to each of the mentions, and remove them of course.)

In my Cypress automated test, to remove a tag from a mention, the tag needs to be created first, so the test creates a tag on the backend before validating that it can be removed on the frontend. However, sometimes it happens that the tag gets created on the backend and does not get propagated on the frontend soon enough, i.e. it does not appear before the Cypress visits the feed page. If that happens when manually visiting the page, which is hard to happen — only in the case of a heavy load on a system, you would need to reload the page and the tag would show up. And that is exactly what I needed to implement in my automated test.

Problems and Solutions

Issue: Sometimes, but not every time, Cypress visits the page too soon before the “tag” element is propagated on the frontend. Solution: Use cy.reload() to reload the window.
Issue: When Cypress does not find an element that you put in the test, it fails with an error that element does not exist. Solution: Use a recursive function* that reloads the window if the given element is not found.
Issue: Edge case alert — if somehow happens that the tag does not get created on the backend at all, the function will end up in an infinite loop because no matter how many times it reloads the element won't be found. Solution: Add a retry increment to each call of the function and add a rule for maximum retries — if the element did not show up after the first or second window reload, it probably won’t at all so throw an error.
Positive outcome: If the tag element is loaded on time or loaded after a window reload, validate that it is visible and continue with the test.

Function explanation:

First Cypress gets an element of one mention.
On that element/mention checks if there is text with the added tag name
First if condition — if the text on the mention does not include added tag name -> reload the window -> call the function again and increment retries by one.
Second if condition — if max retries is equal to retries -> throw an error and fail the test.
If all conditions pass — Cypress checks that the tag on the mention element contains the text of the created tag -> the function finishes -> the test continues with execution

Using recursion instead of loop commands (like while)

Using JavaScript loop commands like while can have unexpected effects because Cypress commands are asynchronous and get queued for execution at a later time. And in my case, if I had used the loop instead of recursion, the Cypress would just pile up “cy.get(‘mention-tags’)” commands to the test chain, without executing any. Then the chain of commands would keep growing but never execute — since the test function would never finish running. The while loop never allows Cypress to start executing even the very first cy.get(…) command.

Final thoughts

By implementing a recursive function and utilizing window reloading in Cypress test automation, we have effectively addressed the issue of elements not being propagated on the front end in time. This solution ensures more reliable and stable test execution, enhancing the effectiveness of our Cypress automated tests.

Also, there are many useful ways to utilize recursion with Cypress. For example, if you need to find a user in a list that has pagination, a function can check if the user’s name is on the first page, if not, click on the next page and call the function again, if the next page can’t be clicked, throw an error that the user is not to be found in the list.

*A recursive function is a type of function that calls itself until your program achieves the desired result.

Find out more:

BDD: Automation Testing with Cucumber

Ajdin Mustafić — Thu, 06 Apr 2023 07:00:00 +0000

Behavior-Driven Development is an Agile software development process that promotes collaboration between developers, software testers (QA) and the non-technical, business side in a software development process.

Outcome of their meetings are structured scenarios which act as requirements for product owners, acceptance criteria for developers, description for stakeholders, test cases and automation scripts for testers.

Our focus in this blog will be on test cases and automation scripts for testers. However, if you would like to read more about BDD itself, you can check out my previous blog which explains the BDD processes more thoroughly.

Cucumber and Gherkin

Behavior-Driven Development is supported by a software tool called Cucumber. It is used to write acceptance tests for the software, and to run the tests in BDD style.

Source: miro.medium.com

Cucumber uses a plain language parser called Gherkin , which is of great importance to the Cucumber BDD approach. Thanks to Gherkin, we can write expected software behaviors specified in a logical and structured language that everyone on the project can understand — from developers to the customers.

Feature File is a starting point of the Cucumber test because it serves as an automation test script and the living documentation. Feature files can contain scenarios, scenario steps, scenario outline, tags and examples. All the feature files end with the “.feature” extension (Login.feature).

Example 1:

Feature: GoogleSearching 
In order to find company information 
As a user
I need to be able to search Google 

Scenario:Google Searching 
**Given** a web browser is at "Google" homepage
**When** the user enters "Bornfight" into the search bar
**Then** links related to "Bornfight" are shown on the result page

Scenario: Video search
**Given** Google search results for "Bornfight" are shown
**When** the user clicks on the "Videos" link at the top of the result page
**Then** videos related to "Bornfight" are shown on the result page

Feature gives information about a standalone unit or functionality of a project. It may also contain Description of the feature (In order to…As a user…I need to be able…).

Scenario represents a particular functionality of a feature which is under test. One feature file can contain more than one scenario, but one scenario can have only one behaviour. If you felt a need to use When and Then more than once in your scenario, it means that there are two behaviours and there is a space for two separate scenarios. Referring to the Example 1, this would be an incorrect way to write the scenario.

Example 2:

Scenario: Google Video search shows videos
**Given** a web browser is at "Google" homepage
**When** the user enters "Bornfight" into the search bar
**Then** links related to "Bornfight" are shown on the result page
**When** the user clicks on the "Videos" link at the top of the result page
**Then** videos related to "Bornfight" are shown on the result page

You probably noticed here that When and Then are repeated, and there are two different actions/behaviours meaning that you should write two different scenarios. By seeing the scenario, any of the stakeholders should be able to understand what is being tested. Scenario is always followed by scenario steps in the Given-When-Then format.

Given — Prediction — Context

When — Action — Event

Then — Outcomes — Result

This is a Gherkin format where the steps must be written strictly in this order and none of them should be repeated. If you want to add more than one line in each step, you can use And or But. Both of them are logically the same, except for the fact that But is used in a negative way.

Example 3:

**Given** a web browser is at "Google" homepage
**When** the user enters "Apple Inc." into the search bar
**And** the user search for images
**Then** the images related to "Apple Inc." should be shown
**But** the images related to fruit Apple should not be shown

Scenario outline , together with Examples , is used when you perform the same test with different data sets. In this example, we checked if all the team members are presented on the company’s web page.

Example 4:

Feature: CheckBornfightTeam
In order to check if Bornfight web is updated with the new team members 
As a Bornfight web visitor I need to see new team member's name in the list 

**Scenario Outline:** Check Bornfight Team

**Given** I am on page "/team"
**When** I look up for the team member
**Then** I should see "<name>" name

**Examples:** 
| name | 
| Kristijan Bujanović | 
| Marko Kruljac | 
| Josip Trbuščić | 
| Ajdin Mustafić |

Steps definitions

Defining all the elements in the feature file doesn’t mean that the tests are ready to be executed. We have defined test scenarios, but the Cucumber doesn’t really know which piece of code should be executed for each line of the scenario. For that reason, we need a steps definition file, a glue between the scenario and the application. In the steps definition file, we have a mapping between each step of the scenario and the code of function to be executed.

In our examples, we use PHP with Codeception and Selenium to write tests and run them in the browser. Here you can see how each line in our scenario looks as a code.

Scenario: Google Searching
 **Given** a web browser is at "Google" homepage
 public function aWebBrowserIsAtHomepage($arg1)
 {

 $this->amOnPage('/'); 
 }

**When** the user enters "Bornfight" into the search bar
 public function theUserEntersIntoTheSearchBar($arg1)
 {
 $this->pressKey("//input[@name='q']", $arg1, \Facebook\WebDriver\WebDriverKeys::ENTER);
 }

**Then** links related to "Bornfight" are shown on the result page
 public function linksRelatedToAreShownOnTheResultPage($arg1)
 {
 $this->waitForText($arg1);
 $this->see($arg1);

 }

Conclusion

This is one basic example of how the scenario steps and steps definitions are connected. However, depending on the requirements of the test and the complexity of the tested feature, writing step definitions can get more complicated. While on the other hand, writing scenario steps should remain basic and easy to understand.

As you can see, the scenarios written in Gherkin are a documentation that’s structured and very easy to understand. A documentation which you can use to run acceptance tests. Also, they are easy to write and edit, therefore we can address them as living documentation. In short, writing feature scenarios in the BDD approach is of great value when it comes to testing, test coverage, documenting features, editing documentation and confirming that the feature works as it was intended to.

If you want to learn more about BDD, check out some of these articles:

Cypress 10: Using Multiple Config Files

Ajdin Mustafić — Mon, 06 Mar 2023 00:00:00 +0000

Running the same tests for different user types using multiple config files

In the Mediatoolkit app, each user organization can have a different pricing plan. Different pricing plans mean that some users can use some features while others can’t. You can check out the detailed feature description for each plan here — pricing.

Recently we changed our pricing plan structure. This means we needed to check every feature for users in each pricing plan. This included running all the same tests and test cases for users in each pricing plan.

How did the multiple config files help?

In our Cypress automated tests, we use the access token, organization id, and query id parameters for logging in and visiting pages to which the logged-in user has access. These parameters are different for each user. If you want to run a test with a different user, you need to change all the parameters or write a different test for each user. We didn’t want to change these every time inside the test code. So, we made config files for each user where we can store their access token, organization id, and query id. This way, when we wanted to run a set of tests for a user with the “Agency” price plan, we’d run the config file we made for that particular user. Nevertheless, in the config file, you can exclude the tests that are unrelated to that user and don’t want to run at all.

By running these tests for different users on different price plans, we validate if a particular user should or shouldn’t have access to the features available in their pricing plan. That way, you can check all the features for one user in a few minutes.

Creating and Running New Config Files

The easiest and safest way to create a new config file is to duplicate the existing Cypress config file (“cypress.config.js). Then, change its name to something new, for example, cypress.development.config.js, and configure it as you wish.

You can run your tests with different config files by running your standard command with added “-config-file” flag and the path to the config file. For example, “cypress run -config-file configs/cypress.individualplan.config.js”

Another way, and a much better way, is by setting a reference in your package.json file with a unique command:

Other use cases

Another use case for our app is running the same tests for different user roles inside one organization. For us, inside one organization, you can be Admin, Analyst, Editor, or just a Viewer. However, much broader use cases are running your tests in different environments so you can have development, staging, and production config files. Or, for example, you can have a config file with a different resolution set up if you want to validate your web application in mobile view.

Feel free to contact me if you have any questions or if you know a better way to approach these cases.

Conditional Waiting in Cypress

Ajdin Mustafić — Wed, 01 Mar 2023 11:00:00 +0000

By using a recursive function, you can repeatedly wait for the request until you get the desired response

Test Case

Our test case involves an existing user (permanent user) who invites a new user via email. The new user receives a registration link and registers for the Determ application. After the new user has been registered and has access to the app, we need to delete them to “clean up” after the test. However, we don’t want to delete the existing user, so we need to check the user ID before deleting the user.

Solution

To delete the newly created user, we need to intercept and wait for a specific API request that contains the user’s access token. However, the same request is also sent for the existing user, and we don’t want to delete them. The only difference between the users is their user ID, which we can only get from the response of the API request.

To solve this problem, we can use a recursive function that waits for the API request and checks the user ID. If the user ID is the same as the ID of the existing user, the function calls itself again. If the user ID is not the same, we save the access token and use it to delete the user later.

Here’s the code for the recursive function:

Then inside your test just call the function:

Conditional cy.wait()

Conclusion

By checking the user ID in the response, we can make sure we only delete the correct user. The recursive function approach can be useful when you need to wait for a specific API request and process its response conditionally. And by using a recursive function, you can repeatedly wait for the request until you get the desired response.

If you have a similar problem or need help implementing this solution, feel free to leave a comment.

How to Read Emails in Cypress

Ajdin Mustafić — Wed, 22 Feb 2023 09:07:33 +0000

E2E Automated Sign up Test

Some people overlook the importance of testing the sign up flow. They might think that’s the first thing that they have developed, tested it over and over while developing other features, and it probably should be working.

However, it can happen that the sign up suddenly starts failing for various reasons. If it does fail, you would want to know it as soon as possible. The later you realize the failure, the more potential new users it can drive off. That is the reason we have an automated test for the sign up/registration flow which gives us a report if something is off, on a daily basis.

Photo by Markus Spiske on Unsplash

Test Flow

For this example, we’ll be going through Mediatoolkit’s sign up and registration page. Here’s how the test flow goes:

User enters their email on the Mediatoolkit sign up page (https://www.mediatoolkit.com/signup)
User opens a link received via email
User is redirected to the registration form
User fills out the registration form
User finishes registration and gets logged in the app
Delete the user (clean up after the test)

Apart from the standard registration flow, I have added the “delete user” step as well. So, after we confirm that the user is registered, we delete that user using API. That way, we get to the initial state which was before the test started. This ensures that the test does not make a lot of junk in the database and is able to run over and over as many times as we want.

Test Goal

Our test asserts that:

A user can enter an email address on the sign up page
A user gets an email from Mediatoolkit
The email contains a valid confirmation link
A user can fill out the form and finish the registration on the link from the email
A user gets logged in after finishing the registration
A user gets deleted after all the previous requirements are successfully validated.

Since our test aims to validate that the email is being both sent and received, i.e. the same flow as the user would go through, I wanted to make it as similar as possible to the real user flow, so mocking this part was not an option for me.

How do I read my emails in Cypress?

As you could see in the previous sections, in order to finish the registration, you need to visit the link that you received in the welcome email. But to do so, you need to access your email inbox, preferably via API. Luckily, I found a blog about the Gmail-tester library by Lev Gelfenbuim which made this test implementation very smooth.

Basically, what you need to do is:

Install the gmail-tester (npm install — save-dev gmail-tester)
Save the Google Cloud Platform OAuth2 Authentication file named credentials.json inside an accessible directory
In terminal, run the following command: node /gmail-tester/init.js

The detailed instructions on how to install and configure the gmail-tester, and your Google account, you can find on the gmail-tester github readme.

Usage in the test

In my cypress-config.js file I have:

And inside of the “module.exports = defineConfig”,

As you may have seen in the previously mentioned blog, this piece of code would be in the “cypress/plugins/index.js”, but since I am using Cypress 10 now, it goes to the cypress-config.js file. Also, the code did not work for me until I added “subject:”, “from:”, “to:” in front of “subject”, “from”, and “to”, which is also different in the blog.

Inside of the test file itself, you should have something like this:

This task checks if there is an email existing in our inbox with the given parameters. Then you can console log the found email. The “html”, in my case, contains the html of the email that we have found in our Gmail inbox. Now, from that html you can take out the confirmation URL or any other information that you need.

Email found assertion

Final Thoughts

Relying on external sources in your test is usually not a good idea. However, if you would like to confirm exactly the same flow as your user would go through, you can try using Gmail-tester which makes it very easy to access an email in your Gmail inbox.

Make sure you visit Gmail-tester Github repository for more information and the latest updates.

Feel free to contact me if you have any questions regarding the implementation.

Phone Number Normalisation

Ajdin Mustafić — Mon, 28 Mar 2022 13:16:42 +0000

The phone number normalisation is used to translate a phone number into a standard form.

For example, there is E.164 international standard which defines format as "[+] [country code] [subscriber number including area code] and can have a maximum of fifteen digits". However, we rarely save numbers, especially domestic ones, in this exact format.

This can be a huge problem if you wanted to allow your users to import their mobile phone contacts into your application. The users can have the phone number, in their phone contacts, entered with or without country code, or can enter country codes like 00385 or +385, etc. So if you didn't have the phone number normalisation, these two numbers 00385991234567 and +385991234567 would be imported as two different phone numbers for the same contact even though when calling, they are the same, just written in different format standards.

We have a similar challenge on one of our projects, so our first step was to research, what should be covered and what others cover when they do the phone number normalisation.

One of my outputs were the test cases that are covered by Whatsapp:

I can't contact a foreign mobile number without a country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Austria, without the country code, Whatsapp will not recognize it as existing.
I can contact domestic mobile number without country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Croatia, without the country code, Whatsapp will recognize it as it is (existing).
I can contact a foreign mobile number with "00" country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Austria, with the 0043 country code standard, Whatsapp will recognize it as existing.
I can contact a foreign mobile number with a "+" country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Austria, with the +43 country code standard, Whatsapp will recognize it.
I can contact a foreign mobile number with "+" country code and 0 before the mobile prefix - For example, save the foreign phone number in your contacts with "+" country code and zero before the mobile operator prefix (+385 0 99 1234567). Whatsapp will recognize and normalise the number to +385 99 1234567.
I can't contact a foreign mobile number with "00" country code and 0 before mobile prefix - For example, save the foreign phone number in your contacts with "00385" country code and zero before mobile prefix (+385 0 99 1234567). Whatsapp will not recognize the number as the same as +385991234567.
I can't contact domestic mobile number with "00" country code and 0 before mobile prefix - For example, save the domestic phone number in your contacts with "00385" country code and zero before mobile prefix (+385 0 99 1234567). Whatsapp will not recognize the number as the same as +385991234567.

Handling phone numbers, especially without normalisation can create a real mess in your application because many users in different countries use different phone number standards to create their contacts.

Feel free to share your experience and your test case examples in the comments section.

Page Object Pattern + Reusable Functions in Cypress

Ajdin Mustafić — Mon, 25 Oct 2021 14:49:33 +0000

If you have ever wished to have more structured, reusable, and readable automated tests, you should have started with the Page Object Pattern.

Page Object Pattern

Page Object Pattern is basically removing all the page information from your actual test and grouping them together considering their location on your web page. For example, you can take all the selectors that you have on the homepage of your web and put them in one class, give them more meaningful names and then call them in any of your tests ...

Imagine your homepage went through a design and development modification that impacted your selectors to change, you would need to go through all of your tests and change the same selector in all the places. However, with the page object pattern, you change the selector only in one place - in the class that you have created for the homepage selectors. There, you saved yourself a lot of time and made sure that there won't be some forgotten, unchanged, and obsolete selectors in one of your tests.

Adding More of Reusability

Nevertheless, you can make your tests even more structured, reusable, understandable, and easier to maintain, by adding custom commands and reusable functions to them. The same way I made a class for homepage selectors I also made a class for all the functions from the homepage, that are used all over the different tests. For example, if I had 5 different tests/test cases where a user fills out the same form, I wouldn't be needed to copy/paste Cypress code to every each of the tests but I'd reuse the already written functions.

Example how my Cypress test would look like with the page object pattern and reusable functions:

describe("Fill out user satisfaction form", function () {

    it("Check if the user can fill out the form", function () {
        cy.visitFormsPage();
        cy.userAcceptsTerms();
        cy.userFillsOutsTheForm();
        cy.formFilledOutCorrectlyAssert();
    });
});

All together now

Combining page object pattern and reusable functions gave me a whole new perspective of the tests. Not only are they easier to use and maintain, but they also look very neat and easier to understand for my other colleagues, even non-technical members of the team. In the beginning, you need to spend a bit more time on the setup but later on, you will see that the effort is paid off.

Feel free to share with me some of your "reusability" secrets.

A Whole Project Team Exploratory Testing Sessions

Ajdin Mustafić — Mon, 24 May 2021 12:14:53 +0000

I love working on challenging projects — they make me think more and I always end up learning a lot of new things.

Our current project is one of those. It has a web platform, iOS and Android applications, a public webstream, and a dozen different user roles. All of those platforms are interconnected and depend on each other, especially with time events where one platform has to pass the information to another in an exact given time frame.

We use the BDD approach on this project — the software tester is included in every aspect of the project, the team is writing user stories, some of the stories are automated, and every user story/feature is manually tested by a software tester. This approach worked well when testing the applications and the features, separately, one by one. However, when we tried to use the platform, all the applications together, we saw that lots of bugs caused by miscommunication or misalignment between the applications could be found. The only way to overcome this testing obstacle was to include more people in the testing process because it could not be done by just one or two software testers.

So, we decided to start exploratory testing sessions with the whole project team. Everyone was included in testing — software developers, project managers, designers, even the CEO. The software tester made the test cases in TestRail and handed out them to the team to give feedback after the testing session. Then the tester would review the feedback and open the bug tasks for fixing.

What else did we gain from this:

We managed to get to the state where more people are using the platform and get their feedback
In a smaller group, we managed to simulate a real user test
The project team got a chance to learn more about the platform's functionality and its features — the fronted/web platform developer got a chance to use mobile applications and vice versa, designers got a chance to see how their design is behaving in the app and the project managers got a chance to see the real state of the project
The developers got a chance to reproduce the reported bugs together with software testers and to understand them better

These sessions were both fun and useful for our project team. Feel free to share your thoughts if you have had a similar situation.

BDD Game: Importance of Shared Understanding

Ajdin Mustafić — Mon, 21 Dec 2020 16:46:56 +0000

At Bornfight, we started using Behavior Driven Development on our projects, about six months ago. From the very beginning, every member of the project team could see the benefit of using BDD. However, it can sometimes be hard to get everyone on board, especially when it comes to having all the project members to talk about features/BDD stories. And if we are not collaborating and not talking about the features, we can not get a shared understanding of the features. If we do not get a shared understanding, we are not doing BDD!

Solution

To overcome this obstacle and to see the true value of collaboration and shared understanding, on one of our sprint retrospective meetings, we decided to play BDD - Shared Understanding game.

The game is very easy to play, but the benefits are far greater. Basically, we needed one person to make some basic drawing (designer) and the other person (project manager) to look at the drawing and take a note (acceptance criteria). After taking a note, the project manager handed us the acceptance criteria and without showing us the drawing asked us to draw it down. We were two backend developers, one fronted developer, a software tester, and another designer.

These were the acceptance criteria:

A large empty circle is located above the horizontal half of the frame, closer to the middle.
In a large empty circle, a little above and a little to the right of the middle there is a small filled circle.
In the plane with a small circle there are 2 small filled circles, one next to the other, but outside the large circle.
The left small circle outside the circle is shaded.
Parallel to the small circle inside the large circle, above, at the top of the frame, there is another small circle that is slightly smaller than the small circles inside the large circle.
2 straight lines are drawn from the middle of a large empty circle, one goes straight down to the bottom - a parallel line, and the other, horizontal line, goes to the edge of the left frame. (Feel free to try it yourself before looking at our results.)

The original was drawn in Figma by one of our designers but the rest of the team could use whatever preferred, Figma or pen and the paper.

Results

This was the original drawing:

And this is how each member of the team perceived by following only the acceptance criteria:

After seeing the original and then seeing each other's drawings we were amazed how everyone understood, the same text, differently. And this was our conclusion:

A picture is worth a thousand words.
It is very important to write clear and accurate acceptance criteria.
It is important to build a common language.
We drew some things based on the assumption and some of them were correct by pure luck.
It is important to revise the acceptance criteria together.
We all think differently and perceive what we read differently.
Different perspectives are not bad. They give us a broader picture and new ideas.
The most important thing is to gain a shared understanding.

So if you work on complex software, when you get the acceptance criteria, talk it through with your project team and make sure that everyone understood it correctly. Otherwise, you can end up dealing with a lot of bugs or even worse, with useless software.

Feel free to contact us if you need help or you'd like to discuss Behavior Driven Development concepts.

Time Manipulation in Software Testing

Ajdin Mustafić — Mon, 28 Sep 2020 09:29:44 +0000

As a software tester you probably already know how important it is to test software’s behavior under different circumstances. One of those circumstances may be watching your software perform while you manipulate with time.

You can time travel to future or past dates, different time zones, leap year, end of the year, month, billing cycle, test the daylight saving time, or just fast-forward to the time that your software requires to finish some action. If you don't want to do any changes to your code, change the system clock, or isolate the server then you should find yourself a tool that will help you.

Benefits:

Early bug discovery in software development - There are some test case examples where you would need to wait for some time to see the outcome of your test. For example, you want to get a notification in your software one day before the end of the month. Instead of waiting, just change the date.
Discovering possible future miscalculations in reports - You can speed up the time to see how will your software behave based upon the parameters that you have entered.
Financial validation - Validate your finances at any point in time in the future.
Workflows testing - See how the events in your workflow will look before you reach them in real-time.
Policy expiration testing - Check if your clients will be notified when the policy expiration date is near.
Data aging/archiving - Check if the data will be archived in the given time.

If you want to expand your testing possibilities, time manipulation software tools are definitely the way to go. Besides you can use them in your automated tests as well.

To start with, you can check some of these tools:

Feel free to share your experience with us if you have already tried using or even automating these kinds of tools.

Cypress Tests in BDD Style

Ajdin Mustafić — Mon, 27 Jul 2020 11:34:37 +0000

Behavior-driven development is an Agile software development process that promotes collaboration between developers, software testers (QA), and the non-technical, business side in a software development process. The outcomes of their collaboration are structured behavior stories which are requirements for product owners, acceptance criteria for developers, description for stakeholders, test cases, and automation scripts for testers.
If you write your automated tests in Cypress and you would like to run them in BDD stories style, you will need to do some additional steps:
1) First, you need to install cypress with cucumber preprocessor module with this command:
$ npm install cypress cucumber cypress-cucumber-preprocessor

2) Then you need to define in your package.json how will you open Cypress:

“scripts”: {
    “cypress-run-cucumber”: “cypress run --config-file cypress/cypress-cucumber.json”
}

Now you can simply start cypress with command npm cypress-run-cucumber

This is our example of cypress-cucumber.json:

{
   “baseUrl”: “http://localhost:3000”,
   “integrationFolder”: “cypress/tests/BDD”,
   “pluginsFile”: “cypress/plugins/cucumber-plugins.js”
}

And our cucumber-plugins.js looks like this:

const cucumber = require(“cypress-cucumber-preprocessor”).default;
module.exports = (on, config) => {
//on is used to hook into various events Cypress emits
   //config is the resolved Cypress config
   on(“file:preprocessor”, cucumber());
   return Object.assign({}, config, {
       fixturesFolder: “cypress/fixtures”,
       integrationFolder: “cypress/tests/BDD”,
       screenshotsFolder: “cypress/screenshots”,
       videosFolder: “cypress/videos”,
       supportFile: “cypress/support/index.js”,
   });
};

3) Also, in your package.json file you should define the path to your step definition:

“cypress-cucumber-preprocessor”: {
        “nonGlobalStepDefinitions”: true,
        “step_definitions”: “cypress/tests/BDD”
    }

4) It is also important to create .feature and .js file with the same name, where .js file must be in a folder, also with the same name. So, for example, you will have:

In login.feature file you can simply paste the BDD story which was the outcome of your team collaboration and in login.js file you should define the steps with Cypress for that story.
Example:
This is your login.feature file:

Feature: User Login
  In order to use the application
  As a user
  I need to be logged in
    Scenario: User logs in with correct credentials
    Given the user is on the login page
    When the user tries to login with correct credentials
    Then he should be redirected to the homepage

This is your login.js file:

import {
    Given, When,Then,
} from “cypress-cucumber-preprocessor/steps”;
Given(/^the user is on login page$/, function () {
    cy.visit(“/login”);
    cy.url().should(“include”, “/login”);
});
When(/^the user tries to login with correct credentials$/, function () {
    cy.get(“[data-test=email-input]“).type(“tester@bornfight.com”);
    cy.get(“[data-test=pw-input]“).type(“test123”);
    cy.get(“[data-test=submit]“).click();
});
Then(/^he should be redirected to the homepage$/, function () {
    cy.url().should(“include”, “/home”);
});

Feel free to comment below if you need any additional explanation or you would like to share your experience on this topic.

Behavior-Driven Development: how to find bugs before coding starts

Ajdin Mustafić — Tue, 17 Mar 2020 09:51:08 +0000

Quality of software should be taken care of from the very beginning of a project. That’s the core of Behavior-Driven Development!

Quality is not something that you add when the project is almost done. Like, let’s add 5 sugar spoons of quality, stir it up and pass it to users. You can compare that to adding a Quality Assurance team to a project when most of the software features have already been developed and changing them would require too much time and effort. Behavior-Driven Development can help you find bugs by involving the QA team and their observation power in the initial state of the project.

What is Behavior-Driven Development

Behavior-Driven Development is an agile software development process that promotes collaboration between developers, software testers (QA) and the non-technical, business side in a software development process. Those three parties, in the BDD process, are usually referred to as The Three Amigos. Their goal is to, by means of collaboration, eliminate all the possible errors in the software – even before any line of code is written.

How do they do it?

BDD has emerged from Test-Driven Development, which is also a test-first approach, whose tests aim to check the application’s functionality (unlike BDD whose tests aim to test the actual behavior of the system from a user’s perspective).

In order to be able to test the behavior of the system, Three Amigos get together, brainstorm and write potential behavior scenarios for testing. The scenarios should be written in plain language that everyone on the project can easily write and understand – both technical and non-technical people, from clients to testers. Furthermore, to avoid misunderstandings, but also to improve quality and avoid missed deadlines, The Three Amigos meet regularly to discuss how the product will be developed.

How each of the Three Amigos contribute to writing scenarios?

Business (Business Analysts, Product Owner, Project Manager) – answers to questions like “what problem must be solved”. They provide requirements and they don’t need to have technical knowledge.
Development – answers to questions like “how will the solution be implemented”. They are technical experts and they build the software.
Testing (Quality Assurance) – verifies that the software works correctly. They need to have some technical knowledge, but not as much as Development.

Behavior-Driven Development Process

At the beginning of the BDD process, the product owner gets as much information as possible about users and their needs. Then The Three Amigos get together and work out the requirements and write structured scenarios in plain English language that anyone can understand.

Written scenarios keep developers focused on delivering precisely what the product owner wants, because the scenarios act like their acceptance criteria and a lodestar during the development process.

For testers, those scenarios can be a base for writing test cases and automated test scripts. This speeds up the testing process and helps achieve greater test coverage.

Product owner shows the scenarios to the user, client or other stakeholders – as they can easily understand what’s written, they can confirm that these scenarios describe exactly what the software should do, or not.

Scenarios written in plain language guarantee that all the people on project, at any point in time, clearly understand what are the requirements and how the software should behave. This helps to avoid any misunderstandings and games of broken telephones. Another outcome is that you have structured and executable documentation, which is very helpful when you need to bring new people to the project or when two different teams build software and do the maintenance.

Here is one made up example – scenario for a feature “Mobile Account top up with credit card” written in plain language called Gherkin.

Feature: Mobile Account top up with credit card
In order to top up my mobile account with credit card
As a mobile user
I need to have a valid credit card with sufficient funds

Scenario: Credit card account has sufficient funds

Given the credit card has sufficient funds
And the card is valid
And the mobile account balance is 5€
And the user enters a valid mobile phone number on the top up page
When the user confirms mobile phone number
And chooses 15€ top up
And enters the correct credit card details
Then the user should see a successful top up message
And the mobile account balance should be 20€

After reading this scenario and the scenario steps, you can easily understand how the feature should behave when the user has sufficient funds on their credit card account. In order to prevent bugs from happening, our goal is to cover as many scenarios as possible. Also, we can use them afterwards to verify that the feature works correctly.

So, for this feature we could also describe scenarios like “user doesn’t have enough money on his account”, “user doesn’t have a valid credit card” or “user’s sim card is inactive”…and many others.

BDD solves the problem of QA becoming agile..

Some companies are still struggling to include a QA team in their agile process, and even though they are doing agile, QA starts with testing and finding bugs at the very end of the software development process. This is usually an expensive and more time-consuming approach. And it is not always just the bugs – sometimes the project team wanders off from the real software objective trying to impress the clients. It’s like building a spaceship for a user that just wanted a Vespa to go to work. These kinds of problems can be recognized by writing behavior scenarios, which is where the QA role comes into play. With their ability to put themselves into users’ perspective, they can advise different behavior scenarios in order to make sure that the project goes in the right direction and to eliminate the “what if?” kinds of questions as early as possible.

Challenges

As BDD is based on collaboration, one of the biggest challenges is that it requires a high level of business engagement and it is usually hard to get business parties to start to collaborate on this level.

BDD pairs nicely with agile software development, but it’s really hard to use it with waterfall – and that is one of its downsides. Another one is that you need to have all of your project people in one place and always on the same page, so it is nearly impossible to outsource, for example, backend developers or a QA team.

Conclusion

If you are doing agile in your software development process, Behavior-Driven Development is an add-on that is worth considering. It could save you trouble finding high-severity bugs during the development process or even after the coding is finished. BDD increases the quality of the software and steers your project in the right direction. Furthermore, it makes it easier to include your QA team in every sprint of the agile process.

If you want to learn more about BDD, check out some of these articles:

The behavior driven three amigos
BDD 101: writing good Gherkin
Writing BDD test scenarios
Behavior Driven Development
Why should designers care about behavior driven development

Behaviour Driven Development – BDD
BDD in action

We’re available for partnerships and open for new projects.
If you have an idea you’d like to discuss, share it with our team!

Forem: Ajdin Mustafić

Reload the window if an element is not found — Cypress Automation

Problems and Solutions

Function explanation:

Final thoughts

Find out more:

BDD: Automation Testing with Cucumber

Behavior-Driven Development is an Agile software development process that promotes collaboration between developers, software testers (QA) and the non-technical, business side in a software development process.

Cucumber and Gherkin

Tags

Steps definitions

Conclusion

Cypress 10: Using Multiple Config Files

Running the same tests for different user types using multiple config files

How did the multiple config files help?

Creating and Running New Config Files

Other use cases

Conditional Waiting in Cypress

Test Case

Solution

Conclusion

How to Read Emails in Cypress

E2E Automated Sign up Test

Test Flow

Test Goal

How do I read my emails in Cypress?

Usage in the test

Final Thoughts

Phone Number Normalisation

Page Object Pattern + Reusable Functions in Cypress

If you have ever wished to have more structured, reusable, and readable automated tests, you should have started with the Page Object Pattern.

Page Object Pattern

Adding More of Reusability

All together now

A Whole Project Team Exploratory Testing Sessions

BDD Game: Importance of Shared Understanding

Solution

Results

Time Manipulation in Software Testing

Cypress Tests in BDD Style

Behavior-Driven Development: how to find bugs before coding starts

Quality of software should be taken care of from the very beginning of a project. That’s the core of Behavior-Driven Development!

What is Behavior-Driven Development

How do they do it?

How each of the Three Amigos contribute to writing scenarios?

Behavior-Driven Development Process

BDD solves the problem of QA becoming agile..

Challenges

Conclusion