Writing dry xcuitest test with base class

In our previous positions when setting up the Xcuitest framework, we built and ran an example xcuitest with Xcode 10. Apple's Xcuitest framework allows us to record basic user journeys and start using Xcuitest, but the recorded tests are not scalable and reusable. We must strive to improve the readability, scalability, maintainability, and reusability of Xcuitest.

As mentioned in the previous article, we can add more UI tests, but there will be a lot of code duplication, which makes our UI tests difficult to maintain and repair. Writing automated tests is easy, but as the size and complexity of the project increases, it is more difficult to write reliable tests. There are various test methods and test patterns available to enable testing to be scalable. In this article, we'll show you how to make the Xcuitest test robust by using swift code that is common in the abstract base class.

Create a base class for the Xcuitest test
Most test frameworks use the base class to abstract the common functionality of the test class. In short, a base class is a superclass that provides common functionality for a test class. In our Xcuitest101xcode project, we have a UI test class. Xcuitest101uitests.swift uses all the methods in a class, such as installation, decompression, and test methods. If we want to add a new xcuitest test, then we have to repeat the setup and disassembly methods for each test class. Obviously, this will create a lot of duplicate code in our iOS project, which makes it difficult to maintain in the future and may prolong your test execution time on the mobile device cloud. To avoid this situation, let's file->next from Xcode->file->new->file->swift and name the file Xcuitestbase, And make sure that the target xcuitest101uitest is selected for the file.

This will create a new file. Xcuitestbase.swift under the UI test target, we can abstract out the common code.

Generic Test workflow
Now that we have created the base class for xcuitest, we can consider common and repetitive code that we can include in the base class. Looking at our existing test class xcuitest101uitest, we can abstract the following in the base class:

Setup and test methods
Instance of Xcuiapplication () which may be required in future tests.
These two are very obvious things that we have to abstract so that we can use them later. However, as projects and test suites grow, more common workflows may need to be abstracted in the future. When you write a xcuitest test, you must configure our application in a state where you can reliably run tests. Apple provides the startup parameters and the launch environment to pass to each test class. It is meaningful to configure the ability to add startup parameters from a base class. A good example is when we want to use the startup parameters to start each test from a clean state.

Xcuiapplication (). launcharguments = ["-startfromcleanstate", "YES"]

This is an example of a startup parameter, but you can pass any parameter or environment created by the iOS developer. We can configure it in the base class, and we can extend the base class to the Xctestcase class, and finally, our Xcuitestbase class looks like this, this:

Now that we have created the base class, the next task is to modify our tests. Xcuitest101uitest to subclasses of the base class and uses common methods from the superclass.

Refactoring the UI test to use the base class
In order to reconstruct our original xcuitest101uitest, we can take the following actions:

We don't need to record the tests, so first of all, let's get rid of testrecorded () our class exam.
Next, we can rename our test methods. Testrefactored () in a more sensible way. When validating the welcome message, let's rename the test to Testwelcomemessage ()
We have to replace the superclass of the test with Xctestcase to xcuitestbase so that we can use all the common workflows in the base class.
Replace the xcuiapplication () to the app from the base class.
After completing the above steps, our test class will look like this, this:

Now our test class looks much better and neater. By using the base class, we reduced the source code for 30 + lines to 8 rows. If you use Cmd+u key, you will see that our tests still pass without any problems. You can get from the debug area, which is usually with cmd+shift+c (??? C) Enter the key in Xcode 10. In our tests, when the test is running in the emulator, the logs are as follows:

Finally, you can see that the test will assert the welcome message and pass.

You try it yourself.
The source code for this tutorial is available here in the BaseClass branch. You can download the source code yourself and run the test in Xcode 10. From the command line, you can get the following source code:

$ git clone https://github.com/Shashikant86/XCUITest101
$ CD XCUITest101
$ git checkout BaseClass
$ open xcuitest101.xcodeproj/
After you open the project in Xcode 10, press Cmd+u to run Xcuitest.

Conclusion
In this article, we abstracted the generic code of Xcuitest in the base class to avoid duplication. However, to make our tests scalable and truly reusable, there are still a lot of improvements that need to be made. We will apply Swift's best test patterns to our xcuitest in upcoming articles. Please keep your eye on it.

Writing dry xcuitest test with base class