Hiya testers! Welcome back to yet another explore-along post on our All-Time Leader for Selenium beginners, “Selenium IDE”!! It’s time to follow closely to get a hold on debugging.
Our goal is ambitious but we are going to take one step at a time.
First off, what is debugging? It is identifying and fixing any errors that might be present in the test case. As simple as that! And it is most important to debug and test our code in order to make sure it works in an expected manner.
Let us get our feet wet! Coming up are different ways to help us debug our buggy test scripts and stay top-notch on the products we deliver!
Breakpoints and Start points
(For detailed explanation, please refer to my previous blog “7i. Selenium IDE – Setting timeouts, breakpoints, start points”)
- Breakpoints give us the ability to run up to a specific command in the test case and stop for inspecting the behavior at that point.
- Make sure to set a breakpoint on the command just before the one to be examined.
- We can set multiple breakpoints in a single test case.
- Start points are useful when we have to run the test case from somewhere in the middle to the very end.
- For example, suppose first step is to login, then perform a series of tests on a website and you are trying to debug one of those. To do this, you can just login once, set a start point after the login section of your test case and rerun as many times as required.
- There can only be one start point per test case.
Stepping through the test case
Yes! ‘Step’ button is used to step through our test cases by executing one command at a time. A closer look at the log pane will show you that one line of log is appended for each command executed. And, you might want to clear the log pane before running the test case as Selenium IDE doesn’t do that automatically. It just appends the newly generated logs to the existing ones.
Time to see an example for better understanding of the ‘step’ feature,
The scenario shown below is quite simple, creating an account in www.amazon.com. A breakpoint is set where the customer has to enter a username. So, all commands up to the one with breakpoint will be executed.
Before clicking, ‘Step’
Once ‘play current test case’ button from the toolbar is clicked, all commands just before the breakpoint are executed. It pauses at the line, “typewait|id=ap_customer_name |user1”.
After clicking, ‘Step’
The “typewait|id=ap_customer_name |user1” line is run and the test case fails. A close look at the log section shows the error along with the description.
The error was due to the unknown command ‘typewait’. By selected the command and editing ‘typewait’ to ‘type’ in the Command dropdown of the ‘Command / Target and Value’ section will resolve the error.
Let us rerun the test case after making changes as discussed. Execution will again pause at “type|id=ap_customer_name |user1” line due to the presence of breakpoint. Click on ‘step’ button in the toolbar.
One command, i.e. “type|id=ap_customer_name |user1” is executed and the customer name as present in the value column of the command is entered on the web page’s “Your name” text box. Execution now pauses at the next command “type | id=ap_email | [email protected]”.
It is important to note that though there isn’t a breakpoint here, the execution is still paused. This is what stepping through means, executing one step at a time – purpose of step feature. It gives us more time to inspect the result of each command, thus helping us fix it. Repeatedly select ‘step’ button until the end of the test case is reached to find out if the entire test has passed.
Takeaway: Clicking ‘step’ button once will execute one command and pause on the next.
Find Button
This might not seem like a killer feature but it is pretty awesome. The Find button is really useful to verify if we are working with / have chosen the correct UI-Element on the current webpage displayed in the browser for the selected command in the current test case.
Select any command whose UI-Element is to be identified and click the ‘Find’ button as shown in the above image. The corresponding element specified by the locator parameter in the chosen command (‘id’ in this case), is highlighted on the webpage displayed in the Firefox browser for a split second in yellow color enclosed within a green bordered rectangle.
Thus Selenium IDE was able to identify and access the element as expected. If it had highlighted a wrong element or detected no element at all on the webpage, then we can make sure that there is a problem with the chosen locator type (more on this in the upcoming blog) or with the script itself.
Page Source
This option often comes handy when identifying a problem. Page source is nothing but the HTML of the webpage under test. Achieving this is really a piece of cake in Firefox browser. A couple of ways are,
- Right click anywhere on the webpage and select ‘View Page Source’. This will open a new tab displaying the entire HTML. Use the search feature, “Ctrl+F” to search for the keyword and to find the HTML portion of the UI-Element we are trying to test.
- Another easy way is to select the portion of the webpage whose source code we wish to see. Now right click and select ‘View Selection Source’. This will also open a new tab but displays only a small portion of HTML, highlighting the code representing the selection made in the webpage.
Aren’t you feeling a bit more empowered after understanding these beautiful features for debugging? Then what are you waiting for? Your feet are wet already, Dive in!
See you again in another post. Have a great day!