It’s common for teams to have a large amount of automated tests on the user interface. When teams start automating tests, beyond unit tests, this is usually the first layer they automate on. It makes sense, as this is a layer a lot of teams are comfortable on, where the knowledge is, and there is a plethora of tools to choose from. Not to mention it’s the layer of the application the majority of customers will interact with.
However, the majority of these tests are usually not very targeted, and typically are end to end, traversing the whole stack multiple times. These tests are easy to identify when they fail, as you have no idea what has caused the test to fail, and usually takes a lot of digging to find the cause. For example you are testing a new order can be made, but you are doing this on the UI going through the whole flow and asserting the user is shown an order ID. If this test fails multiple things could have gone wrong; order ID was the wrong format, order failed, API down, order was made but confirmation screen failed and much more.
The best strategy to adopt is a targeted approach automating on the lower layer that we can mitigate risks. We have a whole host of tools at our disposal these days to enable us to automate tests on the UI, API, Javascript, unit and more. Not to mention different options when it comes to making our assertions.
In this tutorial, we’re going to start with some existing UI tests, which aren’t very targeted and learn techniques and approaches to identify why, and how they could be improved or moved. Once done we’ll then implement those tests and evaluate the improvements we’ve made. This class will be taught using Typescript based open source tools.
