This is the last post in our XCUITest101 series. As of now, we have set up scalable XCUITest and run them on Continuous Integration server. The test executed in the CI server has used headless simulators, however, we also need to set our tests to be executed on real devices. There are many vendors in the market who provides the real devices in the cloud but Bitbar is the pioneer who started supporting XCUITest in the cloud before anyone else. In this post, we will see how we can use the Bitbar’s real device cloud to run our XCUITest tests on physical devices.
So far in the XCUITest 101 series, we have written some XCUITests and explored the XCUITest API. The next step is to run them for continuous testing so that we can get instant feedback on our latest code. The practices of Continuous Integration allow us to schedule and run the test on a regular basis or whenever there is code change. In this post, we will explore how to use XCUITest tests on a continuous integration server.
So far we have covered most of the topics around setting up XCUITest framework and making it scalable and maintainable. However, we haven’t covered the XCUITest API and the other features of XCUITest framework that we can use in our iOS app testing. In this post, we will cover the basics of XCUITest API and how to utilize those API to write UI tests for iOS apps.
In the last post, we have touched upon some best practices of organizing XCUIElements for scalable UI tests with Swift enumeration. While architecting iOS app testing with XCUITests for iOS devices with different screen sizes, we should also consider the scalability and maintainability of our code. We have to make sure XCUITest tests would run flawlessly on all iOS variants without causing a lot of code duplication by architecting XCUITest tests in a proper manner. In this post, we will see some best practices of architecting XCUITests for different screen sizes.
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.
In our previous post on setting up XCUITest framework, we got up and running with a sample XCUITest with Xcode 10. Apple’s XCUITest framework gives us an ability to record the basic user journeys to get started with XCUITest, but the recorded tests are not scalable and reusable. We have to take efforts to make the XCUITest more readable, scalable, maintainable and reusable.
Apple announced the Xcode UI Testing framework in WWDC 2015 that allows us to write user interface tests for iOS apps using Swift or Objective-C. The only option remained to automate iOS apps is the XCUITest framework. Since iOS 10, there is a growing trend of iOS teams adopting XCUITest and deprecating old toolbox. In this short post, we will explore steps to get started with XCUITest to automate iOS app testing with the latest Xcode 10.
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.
2017 was another exciting year for Bitbar. We introduced powerful new features and teamed up with new partners to strengthen our mobile DevOps platform. ‘Speed’ is the single word to be used to wrap up the achievements for the year. We want to take this opportunity to have an annual review.