UI Testing on iOS: KIF vs XCUITests
When it comes to testing iOS apps, the first thing that comes to my mind is "Which framework can help me with that?". There are several options that can help us with this task. In this article, I choose to compare two of them which I've been working recently with: KIF and XCUITests.
KIF — Keep-it-functional
KIF is an open-source, easy-to-use UI testing framework for iOS apps. To start using it you might need something like 5–10 minutes setup with some basic knowledge about dependency management. If you want to give it a try, start with their readme and if you have any questions I will be more than happy to help you, just hit me up in the comments.
XCUITests
This one comes integrated with Xcode, and starting to use it is even simpler and faster than KIF. You can get started by reading Apple's official documentation.
Once you checked both KIF's readme and Apple's XCUITests documentation and/or tried both, here are some points of comparison between these two:
Targeting UI elements
With XCUIT, targeting goes through accessiblityIdentifier, accessiblityLabel and also the content of the element (e.g. text if it’s a label). You have to specify the type of the element, whether it's a button, a tableView, etc.
With KIF, it only goes through accessiblityLabel which might be a problem if you want to support iOS features such as voice-over where accessiblityLabel will be exposed to the user. You can tweak this issue by using the subspec pod 'KIF/IdentifierTests'
A really cool feature of KIF is retrieving the view using waitForViewWithAccessibilityLabel. Once you have the view, you can cast it and call the methods you created for each specific custom view. XCUIT doesn’t have this feature, unfortunately.
TL;DR
XCUIT has deeper search ✅
XCUIT needs UI element type specification ️️❗️
KIF gives you the view, so you can call its custom methods by casting ✅️
KIF needs extra setup to support accessibilityIdentifiers ❗️
Application controlling
With KIF, when the test case is over, the app continues from that point. So, in order to avoid the failure of the whole suite, you must predict exactly where that is. With XCUIT, you can choose when to launch, resume or terminate the app.
This is a bit tricky because sometimes you might experience timeout due to the long time to re-build the app, so it really depends on your .ipa size, the complexity of your UI and how fast everything is before the test actually starts.
TL;DR
XCUIT gives you more control options ✅
KIF forces you to setup a common point in-between the test cases, even with failure ❗️
Test Recorder
Writing tests can be boring and time-consuming. Probably concerned about this, Apple engineers developed the test recorder tool, which is a cool thing to try out because it gives you a sense of maximum automation by coding without tapping the keyboard. I wouldn’t recommend using this tool if you’re looking for precise localization, because most of the times it generates test code that will fail if you change the language of your app .Still, can be helpful in certain projects, and even people without development skills can 'write' tests using this tool — and KIF doesn't have it. So… point for XCUIT ✅
Screenshots
Both frameworks take screenshots when a test fails, which is extremely helpful to understand better what is happening in the UI at the moment of the failure. The only difference here is that XCUIT already has this set when you start using it, whereas KIF needs some extra setup.
One more thing: KIF runs on a unit test target, therefore you won't be able to use snapshot, AND it will run with the rest of unit tests you might have — together.
TL;DR
XCUIT has screenshot when failing built-in ✅
KIF has screenshot when failing but needs some extra setup ✅❗️
KIF uses a unit test target, so you won't be able to use tools like snapshot + all of your unit tests will run together with your integration tests❗️
Performance
XCUIT has a faster setup, but runs slower than KIF tests, even when increasing animation speed. To speed up your animations
KIF tests are faster ✅
Some useful tips for UI testing
You can dismiss the keyboard with ‘\n’ at the end of your string input.
With XCUIT, UITableViews and UICollectionViews are flat, so bear in mind that sections are rows in-between the other rows.
Once you have a nice test suite, consider using snapshot and Fastlane to automate the whole process even more, and if you are using continuous integration tools (e.g. Jenkins or Travis), you can integrate your tests into scheduled jobs to make sure every build meets the expectations.
Tests are executed in alphabetical order according to their names, which have to start with the word ‘test’. (e.g. testA will always run before testB, whether you’re using KIF, XCUI, or another tool)
When you override the class function setUp/tearDown , you’re going to have a unique call of these methods. This is pretty much the same as beforeAll and afterAll in Obj-C.
Some tools that can help you find which view has which accessibilityLabel or accessibilityIdentifier are Xcode UI debug or Accessibility Inspector.
Use constants, especially on views that are used on several screens. This will save you time and effort in case you want to change something and also increase the reusability of your code.
Conclusion
In a nutshell, KIF runs faster and can give you access to the view. XCUIT is slower but requires almost zero setup. It has deeper search but you must specify the UI element type you're targeting.
Both frameworks have nice features but XCUIT is ahead in simplicity and number of features. Using KIF is not difficult, so for this, I wouldn't dismiss an opportunity to try it out. If you have the chance to try one of them, both, or another good testing tool, let me know in the comments! Thank you for reading.
Special thanks to my colleagues Máté Safranka and Gabor Nagy Farkas for thelping me reviewing this article.
If you liked this article, check out some of Supercharge's other articles on our blog, and follow us on LinkedIn and Facebook.
