Write your second test for Synthetic Monitoring – Search complaint
| [0:00:00] | Welcome back to the Checkmk Synthetic Monitoring series. In the last video, sysadmin Bob already created the first test to submit a message in the supermarket complaint portal. Now, in this video, he creates the second test to verify that the complaint actually arrived in the mailbox. This test will log in as the agent, search for the request ID, and check if the complaint appears in the results. Let's go. |
| [0:00:44] | First, we write the second test case name: “Search Complaint.” This test should also open a new page in the browser at the beginning, but this time with a path at the end of the URL. So we will reuse the setup from the first test, but append /mailbox at the end. |
| [0:01:07] | Again, we follow the top-down approach. Instead of implementing everything right away, we describe on this layer what should happen using two high-level keywords: “Login” with “agent” and the password, and “Search Complaint” with the “Request_ID.” |
| [0:01:33] | You will notice I already pass in arguments to these both keywords even before they exist. I do this because I'm lazy. The RobotCode extension also takes the arguments into account when generating the keyword dummies. This is practical and saves a bit of typing. |
| [0:01:53] | But I always recommend to immediately change the argument variable names to make them more descriptive. In this case, “username” and “password.” |
| [0:02:07] | And for “Search Complaint” we just use “id.” Now let's start with the “Login” keyword. I will set the breakpoint inside of the keyword and start the debugger. Now we inspect the login form in the browser, again using the developer tools by pressing F12 and using the element picker. The input fields have the IDs “username” and “password”, and the login button is “login-btn.” |
| [0:02:46] | We can now implement the keyword like this: “Fill Text id=username” and then the variable “username” as argument and “Fill Text id=password” with the variable “password” and “Click id=login-btn.” |
| [0:03:07] | We also test these keywords directly in the running debugger. And we see the inbox... Yes, we made it! |
| [0:03:28] | You might ask, is it really a good idea to use plaintext passwords in tests? Not really. But for the sake of simplicity in this demo we will keep it like this. There is a dedicated library called CryptoLibrary, you will find the link in the description below. |
| [0:03:51] | Now that we are logged in, we implement the second keyword “Search Complaint.” First, I remove the breakpoint from the “Login” keyword and place it inside the “Search Complaint” keyword. Now it's important to debug not only the second test, but always the entire robot suite. Why? Because the first test always determines the ID of the recently transmitted message, which is what we use in the second test. |
| [0:04:23] | I show you now another way to start or debug the test. I click on the test tube on the left. The RobotCode extension displays the test cases in a kind of tree structure, and to the right there are buttons for run and debug. |
| [0:04:37] | “Tests” is the name of the suite file, which is derived from the file name of the robot file. It contains both test cases, and now the test stops inside of the second keyword. |
| [0:04:51] | And now you already know the workflow. Once again, we use the developer tools with F12 and determine the IDs of the elements we want to automate. Its ID is “filter” and the search button is “search.” |
| [0:05:09] | So we type the keywords: “Fill Text id=filter ${id}.” And “Click id=search.” |
| [0:05:18] | We test these keywords again ad hoc in the debug console. Perfect. |
| [0:05:25] | They work. And the table shows exactly the entry with the desired ID. |
| [0:05:36] | And now comes the most important part. We want the test to fail when the id is not shown in the results table. How do we do that? |
| [0:05:45] | In the last episode, you already learned the keyword “Get Text.” |
| [0:05:50] | “Get Text” reads the visible text of elements. But “Get Text id=results” is not enough. |
| [0:05:59] | We want to verify that the request ID is actually included in the text. So we append a condition at the end of the keyword, which is “contains ${id}.” |
| [0:06:14] | This means the keyword only passes when the returned text contains the request ID. Otherwise, it fails. |
| [0:06:26] | To make this even more traceable, we will add a screenshot to the Robot Framework log. The keyword for that is “Take Screenshot.” We pass in two arguments. |
| [0:06:38] | The first one is “EMBED” which embeds the screenshot directly into the HTML log and a selector to limit the screenshot to just the results table. If we leave the selector, the screenshot contains the whole page, but in this way we avoid a full page screenshot and focus only on the important part. |
| [0:07:02] | And with that, we are done also with the second test. I stop the debugger now and run the full suite one more time. |
| [0:07:16] | If everything works, you will see the Robot Framework log file on the right with “PASS” on both test cases. And the complaint ID—it should be right there in the search results, just as expected. |
| [0:07:37] | In this video, we have added the second test to verify whether the complaint really arrived in the mailbox. And this completes our first full end-to-end test. From submitting the form to confirming the data in the mailbox. |
| [0:07:55] | And now it's your turn again. Implement this test on your own and try running both tests together. And also check if your log file says “PASS.” |
| [0:08:08] | Feel free to write down in the comments if you have any suggestions or problems. And in the next episode, we will explore how to make this test production-ready and how to run it continuously from Checkmk with the help of Robotmk. This is the final important step which turns testing into monitoring. |
| [0:08:32] | See you there. Bye. |
Interested in learning more? Register for a dedicated Synthetic Monitoring training course.
