memphispoy.blogg.se - Get and print appium server logs for test case

GET AND PRINT APPIUM SERVER LOGS FOR TEST CASE HOW TO
GET AND PRINT APPIUM SERVER LOGS FOR TEST CASE MANUAL

clicking a button, entering text, scrolling, swiping etc.)

Start and end of each test step (timestamps in sync with the machine(s) running the application under test).

Start and end of each test scenario (timestamps in sync with the machine(s) running the application under test).

Information about the test device/test browser (OS version, screen size, device model etc.).

Version information of the application under test.

In regards to UI automation, these are the actions we suggest having in the logs for each test execution: This becomes more useful when we store log messages in a system which allows filtering (for instance, by these log levels). We can only look at the higher log levels ( ERROR, WARN, INFO) first and enable the lower ones ( DEBUG, TRACE) when necessary. Logback supports TRACE, DEBUG, INFO, WARN and ERROR. Let’s add two Maven dependencies to get started: We use Logback in combination with SLF4J.

GET AND PRINT APPIUM SERVER LOGS FOR TEST CASE HOW TO

We will not cover them in this article but focus on how to optimize log output for plain text or console output. There are great tools for log aggregation and analysis which come with powerful filter and search capabilities. As always, the examples follow a specific tech stack, but the concepts are more generally applicable. This article will discuss some best practices for UI automation using Java-based technologies. Tests with a lot of visual validation might be an exception, but even then a concise log is helpful. Instead, we argue that everything necessary to understand a test execution should already be in its log file(s). However, our point is: videos are helpful but let’s not rely on them entirely. Depending on your implementation, videos might start before the actual test (for example, while the WebDriver is initialising), come in low resolution or with too high a compression rate. At times, automation is slower than human interaction (when the script is waiting for things like potential pop-ups or dialogues) or a whole lot faster (when it is not).

GET AND PRINT APPIUM SERVER LOGS FOR TEST CASE MANUAL

Recordings of automated tests rarely look like videos of manual ones. This works, but it takes time and can be cumbersome. Most test frameworks offer screenshots or videos of the entire run, and many use this for their initial analysis. If we take test automation seriously, every test failure needs to be followed up on and the faster we can gather all necessary information, the less time we waste on it. Which step of the test failed? Which user action is affected, which UI element isn’t where it’s supposed to be, etc.? Did the test reveal a bug (hopefully) or is there a problem in the test script? And probably most importantly, which team or engineer needs to take action to fix it asap. In case of a failure, the question becomes how fast we can figure out why a particular test errored.

We would even question how useful tests are that never fail. In reality, of course, this is not always the case. Green builds, 100% success rate, happy engineers.