#HACKMONDAY – Debugging my first UI Automation Test Sample (PART I)

How to debug your first UI Automation Test Sample

Another One! (DJ Khaled’s Voice). That’s RIIGGHHT; I am back! I wanted to do my first #HackMonday to follow up on my WinAppDriver (WAD) post. This a three-part blog. In part I of the blog, I will debug the Python calculator sample test. In part II of the blog, I will debug my own Python WordPad test.

Background info:

#HackMonday is an idea I came up with as a social experiment. The goal is to #hack with someone new, with the hopes of learning or teaching them something new. For this #HackMonday, I had the pleasure of virtually meeting Hammid Funsho (HI FWEND!)

About Hammid:

A little bit about Hammid, He is a software engineer. He has about 12 years of experience under his belt. He has a passion for automation testing. He codes Java, but occasionally dabbles in Python, and Ruby.  Hammid is currently based out Raleigh North Carolina.

How did I come about meeting Hammid? Great question! It’s simple; I met Hammid on twitter. I saw his profile and liked his software creds, so I asked him if he would be interested in being part of my first #hackmonday. Thankfully, Hammid gracefully accepted my invitation to #hack.

Pre-Requisite:

1. WinAppDriver

2.Windows 10 machine

3. Python 3.6 or 2.7.13

4. Visual Studio Code | Install Python For VS Code

5. Patience

I started off by explaining WinAppDriver to Hammid since he wasn’t familiar with it. (For a recap, click here). Before we debugged my Python Wordpad UI test, I decided to show him WinAppDriver (WAD) in all its glory by running the Python Calculator Test for WAD. The calculator test was a functioning test and should have been an easy way to showcase WAD. To my surprise, the test failed. I must admit, I was taken back by the results since I ran this a couple of weeks ago. I knew for a fact I had not made any changes to the code since I downloaded it from GitHub. So with our best Tom Cruise impressions, Hammid and I went on mission impossible to figure out what went wrong. We started off by comparing the copy of the calculator test I had to the one on the WAD GitHub. We found no differences.

We checked the WAD logged, and we found no 400 errors either. We decided to go back to Visual Studio Code and look at the traceback in the Debug Console.

Here is a video of us debugging the calculator test.

While reviewing the traceback in the debug console, we kept seeing Assertion Error: ‘Display is 8’ != ‘Display is  8 ‘ which means “display is 8 is not equal to display is  8 ”. 

Side note

At first glance, you may not notice anything wrong with the error messages. So we decided to use the print technique to understand what the CalculatorResults value should be.   

def test_initialize(self):

        self.driver.find_element_by_name("Clear").click()

        self.driver.find_element_by_name("Seven").click()

        result = self.driver.find_element_by_accessibility_id("CalculatorResults")

        print (result.text)

        self.assertEqual(str(result.text),"Display is  7 ")

We ran the code and saw that the CalculatorResults value is "Display is 7" but our code was still failing.However, if you look closer, there are some extra white spaces included in one of the “Display is 8”. This was odd since I had not made any changes to the calculator test. To further investigate the issue, we opened up the windows app called Inspect which enables you to view the UI element and see its attributes/ accessibility information.

Upon further inspection, we agreed that there were too many white spaces for "Display is 8" in the calculatortest.py test. So after checking Inspect and verifying this ourselves, we decided to remove the extra white spaces. We reran the test again and this time  S-U-C-C-E-S-S.

Conclusion:

The sudden change in the element “calculatortest” I believe was due to a Windows update that I did on my machine the day prior.  The calculator app must have updated, and the dev team must have removed the extra white spaces which in turn broke the calculatortest.py code.  I learned a lesson. Your environment is always changing, and I find myself asking how could I improve this code so that if there are any additional updates, my code will not break. We could potentially use the strip method or the replace method in python. You can check out an article on how to strip characters from a string from the website below.

https://www.tutorialspoint.com/python/string_strip.htm