In the last post, we organized XCUITest tests in the BDD format by writing Swift extensions in the form of Step Definitions so they are more readable and scalable for iOS app testing. XCUITest identifies the element on the screen by using XCUIElement class. At the moment, we have our locators placed in the step definitions, which means when UI changes in the main app, we have to update all instances of locators from the step definitions. This isn’t a great approach to organizing XCUIElement in the test framework. In this post, we will explore the options of organizing UI elements for XCUITests and why Swift enumeration is the best strategy.
In the last post on DRY XCUITest with Base classes, we have abstracted our code in the base classes in order to avoid the duplication of the code. We have achieved this using the object-oriented inheritance approach. However, Swift is a protocol-oriented language, and we will see how we can use Swift protocols and extension to make our XCUITests more human readable. We will apply Behaviour-Driven Development a.k.a BDD in the methodology for our XCUITest.
Apple released iOS 12 just in time after announcing three new iPhones. The new iOS version has a rich set of features in terms of performance and user experience and comes with huge enhancements in performance, security and privacy. Whilst considering these new features for users, we also need to consider what this release means to every iOS developer and QA engineer. In this post, we will explore some major development and testing considerations for Apple’s new operating system.
The WWDC 2016, the most important annual developer events for Apple, is kicking off in couple of hours. Last year a couple of news or new things were introduced, e.g. debut of Apple Music, the open source of Swift language, new features of iOS 9, and etc. In this year, it’s surely exciting to see how and what Apple is going to bring us to react to the competition from Google and its Android.