One of the requirements of using Appium for mobile test automation is to start the Appium server in the background so that it can listen to the requests from the mobile app under test. And there are multiple ways that we can install and start the Appium server in the background.
Open test automation frameworks are constantly evolving, and at least one new test framework emerges every year and becomes the favorite one among developers. That puts more challenges on the development and testing/QA teams to make long-term planning, since investing in test automation yields results over a longer period of time and test assets cannot be ported to new frameworks frequently without losing a significant amount of the investments.
Folding smartphone rumors have given way to tech demos – and 2019 looks like the year of foldables. But what does this mean for mobile app developers?
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 Bitbar 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.
Challenger banks and financial apps like Monzo, Starling and Revolut might seem like a natural step in the digital revolution, to today’s consumers. Similarly, Netflix and Spotify have disrupted the film and music industries and set digital delivery and a totally in-app experience as the norm. So it hardly seems surprising that banking and financial services have followed the suite – and new apps with fluorescent bank cards seem to launch every week.
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.