1 Repo vs 2: Test Framework Development For Multiplatform Native Applications Using Appium

Question

This question is more of an attempt to gather opinions. I have automated multiple mobile applications that existed as native apps on both iOS and Android. In these scenarios, my go-to pattern has always been to create separate projects for both, rather than attempt to combine the iOS automation and Android automation into one project. In all cases I have used Appium in C# for the test framework implementation. I have tried to search the web and various books (there aren't many regarding the automation of mobile devices) to gain a greater understanding of the preferred methodology to no avail.

This has been a topic of conversation amongst my current company's QA team and so I'd hoped to open the question to the larger QA community and get feedback.

I was hoping for anyone to chime with their own experiences (language doesn't matter in this case) with automating native applications. Did you opt for one project to handle both native applications, or two? In either case, did you find it easy or easier to manage the test automation repositories with one versus the other? What issues arose that you felt it might have been easier to handle had you opted for another route?

Thank you for any input you can provide.

Answer 1

A few years ago we were happy with the approach to have one project to handle both native applications. Appium was also the way to go. But since some recent projects we made the shift to directly use the native testing frameworks (Espresso and XCTest) and not separately, but in the projects of the developer teams. So now there are no additional projects for testing at all.

I like Appium, but this has proven to be the perfect fit for us. There are two advantages in my opinion:

• You are more connected to the development team. This might not sound that important, but now we really are on the radar of the devs. They see our Pull Request. They can also contribute if there is something to add or help. They get a feeling what we are testing. They can easliy execute the tests because it is their domain.
• And vice versa, the QA teams learns from them. We have a much higher understanding of the app code. For example, if you are interested in the matter you can set the accessibility identifiers you need for yourself. Or contribute in any other way to the app code that helps executing your tests. (Disabling Animations, configure test environments etc.)

I know this is not one of the two options that you were stating, but maybe it adds to the discussion. With every new project now we are happy and confident to be in line with the dev team. And I would not want to go back from that.

Answer 2

Why not have three repositories?

The goal of having one repository is avoiding duplication and maintenance of duplicate code. Assuming that your test logic is mostly the same for different platforms, maybe with small adjustments per platform, then you can have one repository containing the common test logic and a different repository per platform containing drivers that implements the steps for the common test logic.

If you want to make even easier to use then the drivers can be libraries or modules installed by a dependency manager like PIP or NPM.

If you think about it that's how Page Object Model works, you have common code describing the functionality and implementation details hidden somewhere.