Write your first test for Synthetic Monitoring – Submit complaint
| [0:00:00] | Welcome back to the Checkmk Synthetic Monitoring series. In the last episode, we helped our hero Bob to prepare a clean and isolated Python environment using RCC and start VS Code from an activated environment. In this episode, it's time to finally build his first test: a test that enters a complaint in the supermarket complaints portal, just like a real user. |
| [0:00:17] | And in this episode, it's time to finally build his first test: a test that enters a complaint in the supermarket complaints portal, just like a real user. First, we will explore the application we want to test. Then we create the high-level keywords, we see how easy it is to find out element IDs on web pages, and then implement the keywords of the first test. |
| [0:00:54] | This is the user-facing part of the application. Here the user enters the subject, the message, and the supermarket location. A short side note about the last field “token.” We want to avoid overloading the app with tests running for a longer time than needed, and for that reason, it is restricted to a time-limited token that you can generate using the green link and have it sent to your email address. |
| [0:01:29] | Once the customer has clicked on the submit button, the site confirms it by showing a unique ID. Then we have the UI used by the support employee. He logs in with the username “agent” and the password, and for your seven-day access, the password is the same as the test token. |
| [0:01:50] | The application is working properly when the message just sent appears in the inbox with its ID. And that's exactly what we are going to automate now. Let's go. |
| [0:02:03] | Since this is a web-based test, we will use the Browser library, which is actually based on the Playwright engine. So for that we type: “Library Browser.” |
| [0:02:15] | You may also have heard of Selenium. There's also a library for Selenium and Robot Framework, but my advice is always use the Browser Playwright library. It is much more modern and faster than Selenium. |
| [0:02:29] | At the very beginning of the suite, we want to launch the browser. The “Suite Setup” statement allows us to execute a certain keyword before the first test starts. The “New Browser” keyword starts the browser. “Headless=False” ensures the window is visible. |
| [0:02:48] | This is helpful while developing. In production, we usually run tests headless silently in the background. To create the first test case, we change to the section “Test Cases” and write the test case name without indentation: “Create Complaint.” |
| [0:03:07] | And similar to the suite, we can also use a special keyword at the test level. It gets executed before the keywords in it are started. For this, we write “Setup” in brackets and “New Page” which opens a new tab with a URL that we pass as argument: “New Page {$URL}.” |
| [0:03:27] | And instead of passing the URL directly, I use a variable. Variables in Robot Framework begin with a dollar sign and a pair of curly braces with a variable name in between. The variable can be initialized in the “Variables” section by just typing the name and the value. |
| [0:03:57] | Before we now write the atomic technical steps, let's outline the logical flow of our test. This helps keep things readable and modular. |
| [0:04:08] | I will write two high-level keywords here: “Submit Form” and “Save Complaint ID.” Don't worry about the red underline. The RobotCode extension just wants to warn that these keywords are not defined yet, but it offers to create them for us. |
| [0:04:25] | Just click the blue icon left to the line and choose “Create Keyword,” and you will see that the bodies of the keywords are created automatically, of course, filled with placeholders. Now let's start with the implementation. I will show you an effective workflow that I always use to develop my tests. |
| [0:04:50] | Let's set a breakpoint in the “Submit Form” keyword by clicking to the left of the line number. Then we start the debugger. The robot then pauses at our breakpoint while the browser is open in the background. |
| [0:05:03] | Now we can inspect the page to find out which names (they are called selectors) Robot Framework can use to access the fields in order to fill them with the values. To show the HTML source, we press F12 to open the developer tools on the right. |
| [0:05:22] | With the activated Element Picker tool, we can click now on a page element and see its representation in the HTML source. For example, the Subject field has the id attribute "subject". |
| [0:05:36] | Let's go back to VS Code and edit our “Submit Form” keyword. I will remove the placeholder lines and write: “Fill Text id=Subject The floor is slippery.” “Fill Text” is a keyword from the Browser library. |
| [0:05:54] | It expects two arguments: First, the selector, here “id=Subject,” and then the text to type in. Now we want to know whether this keyword works. Instead of always restarting the test, I will just copy this line into the debug console below and run it ad hoc. |
| [0:06:13] | A return value of “None” means that it worked. If the selector is wrong, we see a clear error message. And the nice thing about this workflow is that it allows us to instantly interact with the page and continue directly with the other keywords. |
| [0:06:28] | The IDs for the other fields are “message”, “city”, and “token”. “Fill Text id=message I almost slipped at the cheese counter!” Then “Fill Text id=city Munich” and “Fill Text id=token.” |
| [0:06:57] | We also test these keywords again one by one in the debug console. And... it worked perfectly. |
| [0:07:17] | All fields are filled now. Finally the robot should click on the button with the id=“submit-btn” to send the message. You probably guessed it already, the keyword is “Click”: “Click id=submit-btn.” |
| [0:07:36] | We also execute this keyword ad hoc in the debug console. And the app shows us the ID of the message. Great. |
| [0:07:49] | Now we implement the second keyword in the first test case. It should save the message ID. To ensure that the ID is visible after the submission, we add a one-second wait at the end of the previous keyword. |
| [0:08:07] | Ideally, you would add an assertion that waits for this element, but I want to keep the example simple. So let's move the breakpoint to the next keyword “Save Complaint ID.” I now restart the debugger with the green round arrow. |
| [0:08:24] | The first keyword runs through and the robot now pauses at the second keyword. And back in the browser, I inspect the element that shows the ID. |
| [0:08:34] | The id attribute of the “Request ID” is “request-id.” To read visible text from a page element, we are using the keyword “Get Text.” “Get Text id=request-id.” |
| [0:08:52] | Let's try it out in the console... works. This is exactly the ID which is shown on the page. |
| [0:09:02] | By writing a variable before the keyword, the ID is stored there. It's important to note that variables that are created that way are only valid within this keyword. |
| [0:09:12] | But we want to use the id in the second test also. For that reason, we create a second variable “Request ID” which has the scope suite. “VAR ${Request_ID} ${id} scope=SUITE.” |
| [0:09:29] | And this makes the id a kind of visible for the other tests in the whole suite as well. And finally, we can use the “Log” keyword to write the saved value to the log file. “Log The request ID is ${REQUEST_ID}.” |
| [0:09:55] | Great. We have now written our first test case consisting of two keywords: “Submit Form” and “Save Complaint ID.” Let's run the full test once. |
| [0:10:11] | Normally the HTML log from Robot Framework should appear here on the right, but on some systems — I don't know the reason — it's not visible from the very start like here. But we can fix that quickly. Just use the keyboard shortcut Ctrl+Shift+P, on Mac it's Command+Shift+P, to open the command palette and enter the search term settings. |
| [0:10:37] | Then choose settings UI and in the RobotCode entry under extensions, select run. And here change the first entry open output after run from none to log. |
| [0:10:52] | And if we now try it again, the log file opens on the right side in the internal HTML viewer. Great! The button at the top right allows you to open the log in an external browser, which sometimes makes it easier to read. |
| [0:11:08] | The Robot Framework HTML log contains an expandable tree structure of all suites, tests, and keywords inside, including their states. The test “Create Complaint” initially executed new page, and this was then followed by our two user keywords: “Submit Form” and “Save Complaint ID.” |
| [0:11:32] | And we can see that the request was also logged correctly. Great. We now have a working test that submits the form and saves the ID of the message. |
| [0:11:47] | And in the next video, we will use that ID to log in as the support agent and verify that the complaint really arrived in the inbox. And that will complete our end-to-end flow. |
| [0:12:00] | Now it's your turn. Try it out yourself and let me know in the comments below if it worked for you. See you in the next video! |
Interested in learning more? Register for a dedicated Synthetic Monitoring training course.
