Appium Tip #8: How to Take Screenshots on Failure

Everything About Appium Test Automation

We’re continuing our 37 Things You Should Know About Appium with a tip that can be extremely useful for ‘debugging’ your test script execution. When something fails on a test run, quite often you are left with nothing – no trace, no info on why something crashed. Sure, logs can be inspected later on and root cause of failure found, but it is much easier – and instant – to get understanding of failure when you get screenshots aligned with a test run. And those taken when things are going south.

tip#8-thumbnail

Test Case Creation for Mobile Web Testing and Mobile Game Testing

Regardless of which test automation framework you end up using, test case creation on mobile is often very iterative and takes a lot of trial & error to get to the point where things work out up to scale. Every now and then we see situations where tests are confirmed to work locally on a specific device, but once the same test is executed on a variety of device models, problems arise.

Sometimes the problems lie within the device or app behavior changing on different screen sizes, different OS versions or even with specific manufacturers. You can’t always predict all of these behavioral changes between different devices, which is why it is very important to make your logging verbose enough and easy to read. Most of the time one can pinpoint the problem as long as they know where it happens, but sometimes the easiest way to understand the problem is to take a screenshot of the situation.

Selecting the right framework and creating tests that fully cover your app, game or mobile web testing needs are essential to get things moving forward. It’s a well-known fact that automated testing methods can be used for both validating requirements and reducing the costs of testing through automated test case generation – when done right and preferably in the earliest phase of the development.

Let’s move to concrete tip how to gain understanding of failures – and recording those to visuals…

Testing Try Catch Statement

Our samples at Github include the ways to take screenshots. What we want to do is use these screenshot methods in a situation where the test fails. A simple way to achieve this is to enclose your test case into try catch statement, where the first thing you do is take the screenshot, handle any logging you want to display and finally re-raise the error. Re-raising should be used, since the error we got was in this case unexpected and we want to know why.

Here’s how to quickly try this with Python:

def testSample(self):
  try:
    self.driver.hide_keyboard()
    self.driver.hide_keyboard()
  except:
    self.driver.save_screenshot(self.screenshotDir + "/ERROR.png")
    raise

If you try to execute driver.hide_keyboard() when keyboard isn’t visible, you will get a WebDriverException from the Appium server. I placed the command twice, since some devices launch our sample app with keyboard open.

When any command inside the try statement fails, the code inside except statement will get executed. Placing the ‘raise’ command at end is used here to stop the case execution and ensure that exception traceback at end. If you have multiple test cases, the next test case would start running.

Tips on Function Calls and Views

It’s a good practice to include some kind of cleaning process between multiple test cases. The usual way to do that with Appium is to either use the resetApp() function, which effectively re-installs the app being tested. In some cases simply killing the app process on device through closeApp() and launchApp() functions will work fine as well.

Different syntax versions for these commands can be found here.

Testing Calls on Testdroid Cloud and Mastering This Appium Tip

You can also end a test case with driver.quit and then create a new webdriver for the next one, but keep in mind that this will cause your test runs in Testdroid Cloud to separate each test case into its own test session. We recommend bundling up your cases to use the same webdriver instance throughout your test suite, as your tests will then be bundled neatly inside a single session also in the Cloud. This way it will be easier to look at your test results as well!

Stay tuned – more insightful and useful tips for Appium coming out soon in our blog series.

Happy Testing!

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close