We all know it, UI Testing is a pain when it comes to stability and maintainability, but don’t you worry, I might just have what you are looking for! 🧐
That’s right, I made a complete guide for you to get started with stable, maintainable and scalable UI testing in iOS! 🎉
-The first thing you need to take care of is Mocking the Network. You don’t want to let your network requests hit an actual network and there are mainly two reasons for that.
Isolation. Of course, what if your backend friends break their test server? Well, your UI Tests will fail as well, even though nothing is wrong with the app 😱 So now you’ll say “Well let’s deploy a dedicated environment for it then!”. And whose ownership will that be? iOS devs? Or Backend devs? Isn’t that a little bit over-engineering? 🤔 Mocking the Network allows you to avoid unnecessary headaches and “Just re-trigger it!” kind of workflows. 😆
Monitoring. Well yes, if you mock or stub the network, that means you need to predict exactly how many calls are going to be made during your UI test and that’s extremely valuable because you might sometimes find out that your app is actually making unnecessary calls which are eating your user’s data! 😮
Overall, Mocking the Network gives you full control and helps to keep your UI tests stability to a very high standard! 💪
If you want to read more about Mocking the Network, go ahead and check out my dedicated article! 👀
-The second thing you want to address is Stubbing the Navigation. One major pain point with iOS UI Testing is that every test will always relaunch the app entirely. This means that you are forced to go through several screens manually before getting to the one you actually want to test. That breaks the isolation principle, making UI tests hard to debug. 😕
One way of solving this is to inject a stub that will route your navigation in the exact screen you want to end up on. Of course, that also means that your navigation logic must be centralised in a dedicated layer like the Coordinator for instance! 🚦
That way, your UI Tests will suddenly become blazingly fast, but also more isolated, stable and easier to maintain! 🚀
If you want to read more about Stubbing the Navigation, go ahead and check out my dedicated article! 👀
-The third action you might want to take is Disabling Animations. This one is a quick and easy win, simply disabling animations while UI testing will make your tests not only faster but more stable as animations won’t be a potential risk for your assertions. 👍
If you want to read more about Disabling Animations, go ahead and check out my dedicated article! 👀
-🔮 Generating Accessibility Identifiers using Reflection
Until now, Accessibility Identifiers have always been assigned manually. This is a pain and most importantly unnecessary noise in your code so you should avoid doing this. Generating Accessibility Identifiers using Reflection is a great way to get rid of all this manual work, but instead, let your code generate it for you at runtime! 🤯
If you want to read more about Generating Accessibility Identifiers using Reflection, go ahead and check out my dedicated article! 👀
-🤖 Implementing the Robot Pattern
Finally, UI Tests are not only meant to be verifying that your app still behaves as expected, but they also can serve as implicit documentation of how your app works, what the main features are, for your new hires who do not have a clue about the product yet! 😮
Implementing the Robot Pattern will not only help you separate the What from the How of your UI Tests and make screen assertions reusable across UI Tests, but also provide a more human-readable way of specifying tests! 😎
If you want to read more about Implementing the Robot Pattern, go ahead and check out my dedicated article! 👀