Best Practices | Bondar Academy
Course: Mastering testRigor
Module: Introduction
Instructor: Artem Bondar
Lesson Summary
In this lesson, we review the best practices for test triggers to ensure effective test automation. Here are the key points to remember: Best Practices Overview Make Tests Repeatable: Avoid copying and pasting steps. Create reusable rules for common actions. End with Validation: Each test should conclude with a validation step. Follow the Arrange-Act-Assert format: Arrange: Set up preconditions. Act: Perform the action. Assert: Validate the outcome. Readable Tests: Use descriptive names for rules and variables. Interact with elements as a user would, using visible text instead of IDs. User Perspective: Automate scenarios based on how users interact with the application, prioritizing visible elements. No Duplicated Code: Avoid copy-pasting. Create reusable rules instead. Independent Tests: Ensure tests can run in parallel without dependencies on each other. Test Data Management: Store test data in variables instead of hardcoding them in test steps. One Test Case per Flow: Focus on a single user flow per test case to maintain clarity and manageability. Utilize Built-in Functionality: Use Test Rigor's built-in features for stability and performance, such as email testing and smart login methods. Make sure to bookmark the Test Trigger Documentation and refer to it regularly to reinforce these practices in your development process.
Video Transcript
In this lesson before we begin a deeper dive into the test trigger I would like to make a quick review of test trigger best practices Also, I want you to make a bookmark of this web page of test trigger Documentation and review it time to time when you have more experience with this framework just to make sure that you are following all Those recommendation. So let's get into it This is a test trigger best practices page You can quickly find it in documentation and let's quickly walk through this So the first best practice is make tests repeatable so what does that mean so very often in your test you may have some repeatable steps and You don't want to copy paste your steps from test to test So when you notice that you copy in the steps you want to create a reusable rule and then use a reusable rule Later in the test we will have a separate section about reusability and Optimization of test trigger test and we can attach this topic in details later in the class The next one the test should end with validation It's kind of obvious, but you will be surprised how many engineers are actually forgetting adding validations into their test So just walking through the scenarios clicking on the buttons is not a test automation each test scenario have to end with Validation. So the easier approach would be to follow this format is arrange act Assert arrange is you create a precondition for your test act you make an action according to your scenario and then Assert you make a validation of your action and always always add Validations to your test. The next one is test should be easy read to understand Well, this sounds pretty obvious, right? But what exactly that means? So it means that the first of all the naming for reusable rules that you use it have to be very well descriptive So don't make a shortcuts. Don't make any acronyms or something like that so use a good naming for everything reusable rules variables and so on and also, you have to interact with the interface elements from the user perspective, so Use visible text and create human readable reusable rules So for example instead of using ID to click on submit button better to use a visible text on this button Clicking on that Additionally, you can add a comments inside of your test You can use a syntax of double slash and add comments to your steps better explaining what this step is about It's much better to have a descriptive test rather than figuring out what this test is doing And the next one is kind of continuation from the previous one. The test must be written from the end user perspective So when you automate your scenario, and this is I believe the most important best practice of all of them so when you automate your scenario, you have to Perform the steps how user interact with application. For example, let's say you want to automate the Login functionality with username password and click in submit button below the password field and instead of trying to finding ID for the username some CSS selector for the Password and figuring out some ID or whatever X path locator for the button You have to interact how users see the web page So what user see user see the username field or input field and you type your prompt exactly the same way type or enter value into username Then enter password into password and then click sign in below password This is the scenario how user interact with application and using your prompts You also have tried to follow that way So use user visible interface user visible text user visible elements and build your prompts around it Try to avoid hidden attributes such as ID CSS and so on you also can use those kinds of attributes in test trigger when needed But you have to prioritize user visible Interface over the hidden elements that are not visible to the users All right, so moving on so test should have no duplicated code and this is again referring to reusability of your code So don't copy paste the steps from the test case to the test case if you see that you are doing song copy pasting stop right there and Think how you can create a reusable rule for that and just a reminder We will have a separate section in this course about the reusable rule how to use them correctly What is the naming convention have to be how to organize the usable rules variables and so on So just keep in mind copy pasting as bad if you copy pasting stop right there and create a reusable rule Test should be independent from each other so they can run in parallel. So this is very very important So test rigor allows you to run tests in parallel pretty much Unlimited parallel threads because everything runs into the cloud and the more parallel threads gonna run the faster You will get your test results But if you create a test dependency if the execution of the next test dependent on the completion of the previous then you will not be able to do so and Sometimes you may have situation of dependency on the test data, which is hard to see in the beginning But only when you run your test in parallel you figure out Oh my test both of them using the same test account and they're kind of stepping on the toe of each other and Creating a conflict. So when you develop your test always think about okay Is this test has all needed precondition to be executed in parallel? Is this test has a needed test data to be executed independently and in parallel threads? So during the test development keep this thing in mind Test data and specifically test credential are stored in test data So test rigor has a special mechanism for storing a test data. We will talk about it So what this is about is that you don't want to hard code your test data Inside of the test steps you want to save the values for the test data Into variables and then use the reference inside of your test. Also this improves your usability as well So the next one is one test rigor test case for one test So again, do not combine several tests into the single test rigor test case Don't try to put everything at once and at the same time don't try to create your test too small too short too tiny so when you develop your test case focus more on User flow and user journey again, we're talking about the user experience from the user Perspective so automate the flows one by one but do not put several flows into the single test case Otherwise, it's gonna be a mess and hard to maintain and the last one the test should use built-in test rigor functionality for better stability and performance and specifically There is email functionality when you can test the emails if your application sending emails and receiving the emails and we will have a separate lesson about how to test the emails and another method called login Which is a smart built-in method in the test rigor that will automatically can handle a login functionality for you and So on and a test rigor has other useful methods and function and before figuring out some custom approach some JavaScript code and so on check the documentation most likely test rigor has already built in solution For the task that you are trying to achieve. All right, that's it. So that's the list of the best practices So the next step make a bookmark in your browser for this page and verify yourself time to time as a checklist Okay, do I do this check do I do this check and if not try to adjust your habits in the test development Following these best practices the best practice is created for a reason because they allow you to use the framework the most efficient Way. All right. That's it guys and see you in the next lesson