In UI testing, instead, you need to actually interact with the application, in order to trigger events.

Additionally, unit testing tests only code, so to trigger the execution you just need to invoke that code (a method, a class, etc.). The full application must be up & running, while unit testing takes care of performing small tasks, which should be as much isolated and independent from each other. However, UI testing isn't 'easy' to do as unit testing. For example, if our UI doesn't fully support devices with high DPIs, an important button or another actionable item might not be visible, preventing our customers to use the application. The business logic of our application, in fact, can be bug free, but there may be visual issues that we have missed because they happen only on a specific combination of resolution, screen size, etc. However, client applications aren't made only by business logic, but also the user interface plays an important role. This is why we often adopt unit testing, which takes our logic and split it into small pieces, which are tested separately and independently.

When we implement testing, typically we focus only on the business logic side. When we commit new code to our repository, we need to make sure we haven't broken anything before releasing a new version of our application. This is where automated testing comes in.

In order to be agile and deliver fast, we need to make sure that the quality bar is always met. In another post on this blog we have seen how telemetry is important to implement a good DevOps story for your software projects.Īnother important piece of the puzzle is testing.

Appium server showing differnetly