Appium Tip #8: How to Take Screenshots on Failure

We’re continuing our Things You Should Know About Appium with a tip that can help to take screenshots on failure, which is 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 where the root cause of failure can be found, but it is much easier – and instant – to get understanding of failure when you get screenshots aligned with Appium test runs. And those taken when things are going south.

Test Case Creation for Mobile Web Testing and Mobile Game Testing

Regardless of which test automation framework, you will 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. New to Appium? Get our free beginner’s guide for free and learn how to set up a proper Appium environment step-by-step.

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 on how to gain an understanding of failures – and recording those to visuals…

Testing Try-Catch Statement

Our samples at Github include the ways to take screenshots of Appium tests. 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 a 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, in this case, was 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 the 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 the keyboard open.

When any command inside the try statement fails, the code inside except statement will get executed. Placing the ‘raise’ command at the end is used here to stop the case execution and ensure that exception traceback at the 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 the device through closeApp() and launchApp() functions will work fine as well.

Different syntax versions for these commands can be found here.

Testing Calls and Mastering This Appium Tip

You can also finish 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 on Bitbar 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!