iOS is a great platform that offers rich functionality and is amazingly designed from the Agile Development concept with a slight difficulty. Agile is centered on automation tests and requires lots of them when iOS cannot boast with a vast range of possibilities and tools on this frontier.
However there are several splendid frameworks available for your use and comfort granting you the ability of choosing the best fitting one. But you do have to know your cards before you begin hence we are providing this little comparison just for you.
We are seeing an objective-C based framework designed for acceptance testing. This framework was originally written in Square. Now, that the introductions are over let’s get to the strong sides of the framework and it’s weaknesses:
- The framework itself encourages the Actor model for your testing sessions granting a great abstraction level straight to your tests.
- You are writing your tests in Objective-C, right? This means you will not have to make any switches nor will you have to constantly go from production to unit test code.
- KIF 2.0 made all that even simpler by implementing with XCTest directly. It is also integrated with Kiwi and Specta, which is nice.
- The development cycle. Square, the people who were starting this project abandoned it and development was done after by a certain mysterious ninja guy nobody knows of. He has also disappeared over time. Then somebody else took over. Although the person currently in charge is doing a great job I do realize keeping an entire library alone is somewhere in between hard and hellishly impossible. This may not end up in a good manner.
- KIF is not consistent at points. False failures are something that happens way too often with KIF and if you cannot trust your own tests why run them in the first place?
Conclusion: If Objective-C tests is what you love need or will be using for whatever else reasons you may go for KIF.
Frank gives itself the credit of being the Selenium for iOS. Although I’m not buying that the framework however deserves some attention. If you want a piece of Frank you will require injecting a small framework sample inside your apps special build. The framework will be doing the job of a local server. You will be able of interacting with that server throughout your testing session. Commonly tests are written either in Ruby or Cucumber.
- There are many people who love Cucumber and Ruby and Frank is just the framework for them.
- Frank grants you direct access to a UIAutomation framework vie exposing it with a library. This way is significantly better than commonly used libraries which are synthesizing their personal touch events.
- You may not enjoy Cucumber or Ruby.
- There is a context switch between test and production code required.
- This project is being developed in a strange manner. Each core library has 2 different versions that are under various GitHub organizations. How should one know the right version? Where were these or those updates from? Confusion is generally all that may be gained with such an approach.
- There is this necessity of maintaining another target for acceptance testing purposes only. It’s not that this adds extra amounts of overwork that are inacceptable or unappropriated. This thing is just irritating. Like a lot.
Conclusion: despite all pitfalls this solution is OK and loved in the community however I can’t say it is my thing.
The rest is your choice, guys as you will be the ones caught in the iPhone app testing session.