DEV Community: Auksė

Data-* attributes. Hook your automated tests on proper selectors.

Auksė — Mon, 02 Dec 2019 09:26:31 +0000

It is often a discussion about the best practice on selecting elements while writing UI automated tests. Recently I started using ‘data-qa’ attributes instead of IDs. In this article, I share my experience and provide some examples on this topic.

Why data-* attributes?

If you need to update every single test after each code refactoring - it’s time to think about a better way of describing the page elements. From my experience, I used to add IDs, but is that the best way to select an item? Let’s talk about the most common selectors.

Class attribute. The purpose of the class attribute is to style elements. This attribute can be changed very often and you’ll be forced to refactor your tests frequently. You can make your own class naming convention, however, the class purpose is different - you need to use things for what they are meant for.

ID attribute. The purpose of ID is to have a unique reference that is not repeated on a page. So if you have a list on your page - ID is not such a good idea. Even if you use an array of the same IDs, it is no longer unique.

Data-* attribute. According to the definition “The data-* attribute is used to store custom data private to the page or application.” This “ghost” attribute can simply be used for automated tests and does not affect the element selection in CSS and code logic in javascript. That’s why I decided to use data-* attribute.

In my tests, I name this attribute “data-qa”, but you can choose any other name you like, just don’t forget to add the suffix after “data-” by defining any string as a value. By the way, if you seek efficiency and need those attributes in code without asking permission from the devs, then you need access to the project source.

So you get the flexibility of the element not being related to the content or style, however, there is one ‘but’: when you need to test if the element name (e.g. button name) has changed, don’t forget to add ‘contains(text)’ to your data-* attribute. For example, your data-qa attribute is ‘homepage-btn-continue’ on the homepage and you want to be sure, that this button name was not replaced.

Convention with examples

Convention or in other words, agreement on how to describe various web page elements is very important. I like to say - if anyone can understand the defined element without additional explanation - you did the naming right.

My goal was to make the tests readable and understandable directly from the code. It means another person should be able to easily understand which element will be clicked in a certain test by reading a test script.
Data-qa attributes convention in our team consists of different cases. Below I will provide some of them:
Do not use random names and numbers;
If there is one element per page:
Add a page name, element type (abbreviations can be used) and element name, for example:

If there are more same name elements per page:
Add page name, element type (abbreviations can be used), element name or a part of the name and additional element type. For example, two buttons are called “Explore Templates” on the same page. So I’ll add the section name to the end of the row:

If the element is in the modal window:
Add modal window name, element type (abbreviations can be used) and element name, for example:

So that is the fragment of the convention we use. These guidelines help us to have clear and descriptive selectors.

Conclusion

In this article, I have shared one of the possible ways to make a small improvement in your automated tests. Of course, you need to add those data-* attributes by yourself. For me, it is a great way to simplify automated UI tests. You can select elements easier and make your tests easily readable. What is your experience on this topic?

E2E Testing Explained in Simple Words

Auksė — Mon, 02 Dec 2019 09:10:25 +0000

E2E (end-to-end) testing — this term is already very popular in software testers’ lives. I think it’s not just a trend, but more of a necessity for our daily work and especially for regression testing.
However, I noticed that many IT specialists have a different understanding of E2E testing, and I heard a lot of discussions around this topic. So, I decided to delve deeper into the E2E testing world.
I will try to summarise my observations and give you some advice regarding E2E testing.

What Is the Purpose of E2E Testing?

When you start using a new tool or methodology, you have to know how can it be useful and how it can help you to improve your project.
So what is the main purpose of using E2E tests? In short, it helps us to automate a particular user — flows from start to finish — and verify the system with interconnected systems as a whole.
Of course, I can choose the unit or integration testing types and create beneficial test scenarios. The difference is that by using E2E tests, you are simulating a real user scenario.
Imagine you are a user who wants to update his payment card data because your previous card has expired. One of the E2E test examples would be:
Login into the system
Navigate to your profile
Remove your existing card
Add a new card with valid credentials
Save updated info
Logout
In this example, you should use the call method for an already created login test case as your first step. Then, verify if the success message is displayed when you are saving new info. So, don’t forget to combine the steps from already created tests, but remember that the E2E test should be independent.
Keep in mind that E2E testing is not just a happy path testing — end-user can enter invalid credentials or use incorrect data, so pay attention when you are creating test scenarios. Hence, do not forget its core idea — by creating E2E tests, you need to act you were an end-user.
Unit, Integration and E2E Tests — Do We Need All of Them?
When we are talking about E2E testing it would be a mistake not to talk about other testing types — unit and integration.
E2E testing is the youngest child in this group, but how does it differ from other types?
Let’s say you need to test a username update in the user profile — save a new value. In the example below, you can see the differences between those testing types.
UNIT TEST. By using this type of testing you will create a lot of test cases to test if save function works well.
INTEGRATION TEST. You will be able to create separate tests that verify if a username is saved in the database after an update and is displayed properly in integrated systems.
E2E TEST. By using this type of testing you will create a user flow from start to finish — you will test if a user is able to log in, is able to navigate to his profile, enter a new value, save that information and see updated profile info properly.
There is no correct answer to which type of testing is better. Every type can be useful if you create effective test cases.
E2E Testing Strategy
E2E testing can be difficult to implement, so before writing E2E tests you need to think about the E2E testing strategy. In this section, I will provide some useful steps that can help you during the very first steps of the E2E test implementation.
System knowledge. Manual and automated testing share many similarities. You cannot start automation without the essential system knowledge unless you get a specific task, and your responsibilities are just to write the code.
If you are responsible for all of the quality processes in your project and you want to automate E2E tests, you should know the general key points about the system that you are going to write test cases for. So don’t be in a hurry, concentrate and when you feel comfortable about the end-user flows — it’s time for E2E testing.
Automated E2E test case structure. Another important aspect to start writing automated tests is the structure of test cases. Regarding your manual test cases and system domain you should decide how to divide automated test cases, for example:
critical functionality
basic functionality
edge cases functionality
What is the idea behind such structuring? From automated tests perspective — they can be slow and take a lot of time to run, so by separating tests into categories we can run critical automated tests in our CI build tool more often. This way we can get much faster feedback while leaving basic/edge case automated test cases on a daily run.
The importance of choosing the right tool/framework. One tool is not always fit for all the products we create. Nowadays we have a lot of automation possibilities. So before choosing the best solution to implement automated E2E tests, I suggest you prepare a checklist of criteria according to the scope of the project, resources and etc:
Maintainability — your system can change often and already automated user flows require to be updated from time to time. Automation testing should not be stressful and you should not investigate a lot of your time to update tests.
Built-in framework — E2E tests should be easy to set up. I always try to keep that in mind when choosing the tool with an already built-in framework because you can save a lot of time and effort.
Community support — I prefer using a tool with clear documentation and community support. If something goes wrong, you are able to get the answers fast.
Less is More. If you are familiar with testing types pyramid, you should know that when you are moving up that pyramid, your tests become larger in scale, but at the same time, the number of tests is reduced, meaning that E2E testing is not about quantity.
Conclusion
E2E tests are important — but you can’t rely on them only. Steve Freeman, the author of “Growing Object-Oriented Software, Guided by Tests” once said: “Running end-to-end tests tells us about the external quality of our system, and writing them tells us something about how well we (the whole team) understand the domain, but end-to-end tests don’t tell us how well we’ve written the code. Writing unit tests gives us a lot of feedback about the quality of our code, and running them tells us that we haven’t broken any classes — but, again, unit tests don’t give us enough confidence that the system as a whole works.”
So, do not forget to think from the perspective of your product — about its specifics, its challenges, and build your E2E testing strategy on that.

E2E Testing Explained in Simple Words

Auksė — Thu, 12 Sep 2019 13:46:50 +0000

What Is the Purpose of E2E Testing?

Login into the system
Navigate to your profile
Remove your existing card
Add a new card with valid credentials
Save updated info
Logout

In this example, you should use the call method for an already created login test case as your first step. Then, verify if the success message is displayed when you are saving new info. So, don’t forget to combine the steps from already created tests, but remember that the E2E test should be independent.
Keep in mind that E2E testing is not just a happy path testing — end-user can enter invalid credentials or use incorrect data, so pay attention when you are creating test scenarios. Hence, do not forget its core idea — by creating E2E tests, you need to act you were an end-user.

Unit, Integration and E2E Tests — Do We Need All of Them?

When we are talking about E2E testing it would be a mistake not to talk about other testing types — unit and integration.
E2E testing is the youngest child in this group, but how does it differ from other types?
Let’s say you need to test a username update in the user profile — save a new value. In the example below, you can see the differences between those testing types.
UNIT TEST. By using this type of testing you will create a lot of test cases to test if save function works well.
INTEGRATION TEST. You will be able to create separate tests that verify if a username is saved in the database after an update and is displayed properly in integrated systems.
E2E TEST. By using this type of testing you will create a user flow from start to finish — you will test if a user is able to log in, is able to navigate to his profile, enter a new value, save that information and see updated profile info properly.
There is no correct answer to which type of testing is better. Every type can be useful if you create effective test cases.

E2E Testing Strategy

E2E testing can be difficult to implement, so before writing E2E tests you need to think about the E2E testing strategy. In this section, I will provide some useful steps that can help you during the very first steps of the E2E test implementation.
System knowledge. Manual and automated testing share many similarities. You cannot start automation without the essential system knowledge unless you get a specific task, and your responsibilities are just to write the code.
If you are responsible for all of the quality processes in your project and you want to automate E2E tests, you should know the general key points about the system that you are going to write test cases for. So don’t be in a hurry, concentrate and when you feel comfortable about the end-user flows — it’s time for E2E testing.
Automated E2E test case structure. Another important aspect to start writing automated tests is the structure of test cases. Regarding your manual test cases and system domain you should decide how to divide automated test cases, for example:

critical functionality
basic functionality
edge cases functionality

What is the idea behind such structuring? From automated tests perspective — they can be slow and take a lot of time to run, so by separating tests into categories we can run critical automated tests in our CI build tool more often. This way we can get much faster feedback while leaving basic/edge case automated test cases on a daily run.
The importance of choosing the right tool/framework. One tool is not always fit for all the products we create. Nowadays we have a lot of automation possibilities. So before choosing the best solution to implement automated E2E tests, I suggest you prepare a checklist of criteria according to the scope of the project, resources and etc:
Maintainability — your system can change often and already automated user flows require to be updated from time to time. Automation testing should not be stressful and you should not investigate a lot of your time to update tests.
Built-in framework — E2E tests should be easy to set up. I always try to keep that in mind when choosing the tool with an already built-in framework because you can save a lot of time and effort.
Community support — I prefer using a tool with clear documentation and community support. If something goes wrong, you are able to get the answers fast.
Less is More. If you are familiar with testing types pyramid, you should know that when you are moving up that pyramid, your tests become larger in scale, but at the same time, the number of tests is reduced, meaning that E2E testing is not about quantity.

Conclusion

E2E tests are important — but you can’t rely on them only. Steve Freeman, the author of “Growing Object-Oriented Software, Guided by Tests” once said: “Running end-to-end tests tells us about the external quality of our system, and writing them tells us something about how well we (the whole team) understand the domain, but end-to-end tests don’t tell us how well we’ve written the code. Writing unit tests gives us a lot of feedback about the quality of our code, and running them tells us that we haven’t broken any classes — but, again, unit tests don’t give us enough confidence that the system as a whole works.”
So, do not forget to think from the perspective of your product — about its specifics, its challenges, and build your E2E testing strategy on that.