Swift Driver for Appium Automation Testing with Dalton Alexandre

[00:00:35] Hey, it's Joe and welcome to another episode of The Test Guild Automation Podcast. And today, we'll be talking with Dalton all about a new Swift driver for the Appium framework and also UI testing in general. If you don't know, Dalton is a self -taught Swift developer currently working at, I think it's a multi -platform UI automation for Milc Group, which I think is a Dairy ERP software. We'll find out more about it. You don't want to miss this episode when learn more about automation, UI animation, mobile automation, Appium framework, and a bunch more. Check it out.

[00:01:05] All right, before we get into it, I want to give a big shout out to this week's episode sponsor, BrowserStack AppLive. If you don't know, BrowserStack App Live is a cloud-based platform that allows developers and testers to interactively test their mobile applications on a wide variety of real Android and iOS devices. With support for various OS versions and device manufacturers, App Live eliminates the need for maintaining a personal device cloud, providing instant access to real devices for testing. Some key features are real device testing. So you can test your mobile apps, over 20,000 real devices without any setup, maintenance, or hassles. You get multi-device testing. So you can run tests on two devices simultaneously in one session, allowing for efficient testing of different scenarios. You also get low-code testing to test apps that require access to internal services or staging environments securely. It has native device features that help you to replicate real user conditions by utilizing features like GPS network simulation and more. It comes with debugging tools where you can access DevTools for inspecting UI elements, monitoring network requests and tracking app performance. BrowserStack App Live offers a robust solution from mobile app testing that enhances productivity while assuring high quality user experiences by providing access to real devices and advanced testing features and empowers developers to identify issues early in the development cycle, ultimately, leading to faster releases and improved app performance. If you haven't already, make sure to support the show and give BrowserStack App Live a try and see how it can streamline your testing process using the special link down below.

[00:02:46] Joe Colantonio Hey, Dalton, welcome to The Guild.

[00:02:50] Dalton Alexandre Hey, thanks for having me.

[00:02:51] Joe Colantonio Awesome. So I guess before we get into it, is there anything in your bio that I missed that you want the Guild to know more about?

[00:02:57] Dalton Alexandre No, you pretty much nailed it all. I've self-taught really began in 2019, focusing on Swift and recently took up this employment last November and through that have developed this driver to assist my role in writing UI tests for our company here.

[00:03:16] Joe Colantonio Yes, I guess that was one of my first questions is why did you create this particular driver?

[00:03:21] Dalton Alexandre Yeah, I originally was developing iOS applications and had the comfort with Swift and writing packages. And when I was looking into scripting these automations for this, for Appium specifically, I saw how the other languages were structured as packages and knowing sort of taking a guess that a Swift package functions in a similar manner, I decided to write a Swift package that interacts with the Appium server in the same way the other drivers do. And there wasn't much documentation or actually none for Swift. And so I was able to take my experience and kind of integrate the two together.

[00:04:09] Joe Colantonio It's interesting you self-identify as a developer.

[00:04:11] Dalton Alexandre Yeah.

[00:04:11] Joe Colantonio Why are you using Appium? A lot of times people that are developers will use iOS native or other ways to automate.

[00:04:20] Dalton Alexandre Originally, the idea was to use the native Espresso framework for Android XC testing for iOS. And then the web test was where the decision came to go multi-platform. Most of the functionality of our application is performed on the web. And so being able to have the setup happen through the web but then still transfer over using the multi-platform structure to complete the automations really was advantageous to us in making a suite that was fully comprehensive and could be transferred across the domains here.

[00:05:05] Joe Colantonio Was there a choice between fast and comprehensive? A lot of people complain about Appium being slower or it could just be the way they're developing it and that's making it slow. Have you seen Appium is slower than the native frameworks?

[00:05:19] Dalton Alexandre I really haven't. The limitations aren't with the Appium framework at all. It's really with getting the network up to speed. Logging in takes some patience, as does waiting for certain web pages. But some delay helps in structuring that. But usually when writing the test, I've yet to see any limitation in speed.

[00:05:43] Joe Colantonio Great. So if people are already familiar with Appium, how hard is it to get up to speed with Swift Appium? Is there, has it integrate as any tips on how to get up and get it up and running?

[00:05:54] Dalton Alexandre The most difficult part is connecting your individual devices, and that's really figuring out how the sessions communicate through Appium to your device. But once you understand how to set up the driver in that regard, I think it's fairly simple in understanding what does what within the driver. And to elaborate on that, just recently released this and it's very bare bones to what the use cases I'm using. It's not comprehensive in utilizing the entire frameworks in that if others have suggestions to how usefulness they should incorporate, that's definitely open.

[00:06:43] Joe Colantonio What do you mean it's bare bones compared to what you're using? So you're using it to do more awesomeness than what you've released to keep it as vanilla as possible get started?

[00:06:51] Dalton Alexandre Pretty much. Yes. In comparison to the other drivers, the list of APIs that it's utilizing off of Appium is fairly minimal. Clicking and sending keystrokes to fill out forms, but generally, there isn't much complexity. I had screenshots in there originally, but we weren't using them, so I've taken them out. If someone finds that they could use that as well, it wouldn't be difficult to add back in.

[00:07:22] Joe Colantonio It sounds like it's low overhead. What are any core dependencies that I needed for someone to get up and running with it?

[00:07:27] Dalton Alexandre No, Swift generally, and I personally have been using Swift testing, which is the new open source framework to integrate it. But an understanding of Swift and Swift package manager is useful in running it as an executable.

[00:07:46] Joe Colantonio Alright. I actually haven't heard of Swift testing. Was that a library for Unit testing?

[00:07:50] Dalton Alexandre Correct, correct. Yeah, it is specifically unit testing at this point. There is no UI framework associated with it, but it's an open source project that was released last June and has small community around it, but the idea of it is to replace XC testing over time, as well as utilize a lot of the new Swift language abilities. Macros for example, are heavily used as our different type safety possibilities.

[00:08:22] Joe Colantonio What you say, it replaces X? Xcode.

[00:08:23] Dalton Alexandre XC test.

[00:08:28] Joe Colantonio XC test.

[00:08:28] Dalton Alexandre So yeah, that's the unit testing typically done with iOS.

[00:08:32] Joe Colantonio Why do you want to replace it? Because it's the same language as what are the reasons why you would replace?

[00:08:37] Dalton Alexandre Generally, the parallelization of Swift testing is one of the major reasons. The concurrency that Swift has had in the last year or so is definitely utilized in Swift testing. In my use case though, specifically I run the test serialized, which is just a configuration in setting them up, but that has to do with needing to call the commands to Appium at certain times, but generally for a Unit test, you're able to parallelize all your tests to where a testing suite that usually took quite a bit of time can run much, much faster.

[00:09:12] Joe Colantonio Gotcha, gotcha. So are you using real devices or simulators to use Swift with?

[00:09:17] Dalton Alexandre Yeah, originally it was simulators. I now have a sample of devices to run the mobile test on, but a majority of my tests so far have been web-based as most of the functionality for our team is off the web to begin with. But I found the limitation for myself in the server I was using that a parallelization of emulators was RAM heavy to where I definitely had more luck running off of individual devices than spinning up multiple emulators at once.

[00:09:54] Joe Colantonio Very cool. Why Swift? Is it because your applications ran in Swift and you just want to keep everything the same code base?

[00:09:59] Dalton Alexandre Yeah, pretty much. I'm comfortable in Swift. I appreciate a lot of the functionality that's gone into the language, not opposed to learning other pieces of languages as I need to. The NPM hasn't been difficult with Appium to understand just how to set up Node as I've needed it, but the ability and customization that Swift allows me has been comfortable and I appreciate a lot of the features that have been added to the language in recent years, the concurrency, for example, has helped quite a bit.

[00:10:33] Joe Colantonio How hard was it to start? I think a lot of people like, oh, I have this personal itch. I need to itch. I want to create this. How hard was it to create this open source project and contribute to the Appian project at large?

[00:10:45] Dalton Alexandre Not very difficult to begin with. I had a discussion with my boss and asking if this was all right. Like what parts and pieces were I was able to share. But then in discussion with Appium, it was as simple as a pull request with the ideas of including some Swift code and they were all very receptive and lined out parameters for myself to continue helping maintain that for a while, at least help get it off the ground like initially as was submitting it, it had been so bare bones. Like I had yet to include a readme. And so they had asked for some documentation and an overview of it.

[00:11:31] Joe Colantonio Nice, were there any challenges when developing Swift Appium? It sounded like documentation was hard to come by. I don't know, was there anything else.

[00:11:38] Dalton Alexandre At times, there has been some confusion. It could be my inexperience in other languages. I think my naming is slightly varied from the naming of the other drivers. I tend to have used client as, whereas other drivers use driver. I don't know if that's something I may adjust over time or by suggestion, make some edits to. But knowing what I wanted to accomplish was also the difficult part. Most of the interaction is through the web driver and the different APIs that communicate with Appium. Weren't obvious to begin with, but over time have allowed more functionality. I did begin the web automation on Safari, but after some issues in identifying pieces of the web page, which may have been an issue with the framework we use for the website, which is React, or an issue from Safari and the Safari WebDriver. I eventually transitioned to Chrome and have had more success there using the Chromium plugin rather than the Safari.

[00:13:01] Joe Colantonio Why is that? Just because Chrome probably has better support?

[00:13:04] Dalton Alexandre I think so, yeah, initially. And Appium gone through a new update and I don't know if Safari driver is completely up to speed with some of that.

[00:13:22] Joe Colantonio Nice. Did you need to get the blessing? You said you did, they did ask you for a readme, but do they look at your code and say, oh, you should call list driver, rather than client?

[00:13:31] Dalton Alexandre No, there has been no adjustments asked of the code itself, which all right with, but I would happily take suggestion in that this is the first few months of testing for myself. And so any advice or suggestion is greatly appreciated.

[00:13:49] Joe Colantonio Nice. So have you gotten any feedback from anyone yet? I know it's very, very, it's fairly new.

[00:13:55] Dalton Alexandre One star on GitHub so far. Thank you.

[00:13:59] Joe Colantonio Hey, you need one to get to many. So that's good start. Cool. So any recommendations why people should contribute to open source projects or give this a star or fork it, maybe a plug for why you think Swift Appium people should try it and give it some love on Github.

[00:14:16] Dalton Alexandre Yeah, there's definitely usefulness in having a testing framework in general. And I have a friend of mine who uses UI tests to generate his own screenshots, for example. And so there is functionality that can save you quite a bit of time. And Appium could be a solution in that regard. The use case I'm using it for is running a suite of UI tests that look for certain bugs to make sure the functionality is correct throughout, but the contribution to open source is also one of the best educational outlets. I can't compare much because the ability to make a suggestion or make a change to some code or have some sort of input that you then have someone else review and merge, it's a great feeling as well as it adds to your ability as a developer in so many ways in learning in how they want their projects structured, teaches you a lot about how different code bases work, as well as defining techniques that you can definitely take elsewhere.

[00:15:32] Joe Colantonio Right, cool. If someone's listening to us, they've already used Appium, but they haven't used the Swift Appium. How hard is it would it be for them to get started? What would they needed to do?

[00:15:40] Dalton Alexandre Some understanding of Swift is useful, and setting up a test is the first role where you have to communicate with the client. I currently use an asynchronous HTTP client to communicate with the Appium server. And then after the client has established that communication between the server and your test, then you have to send over the information about the device you want to work with, and that creates your session. And that session is then used throughout your entire test, whether you're interacting with an element, pulling the entire element hierarchy to see what's on the screen at that time or sending keys over the session and the client are the two main pieces that you need. And then depending on what sort of test you're running, whether you're running an executable Swift package that runs continuously and then just ends, or you're running it as a testing suite, in which case you would have to de-initialize the client at the end to allow the asynchronous HTTP client to gracefully shut down as it's put.

[00:16:58] Joe Colantonio Nice. Once again, you said you started off as bare bones. Is the reason why you started as bare bones? Because you wanted people to contribute? Or is it because you just wanted to start as quickly as possible and then stop merging in all this, all the stuff that you have that maybe isn't quite ready for prime time.

[00:17:14] Dalton Alexandre Yeah, I don't want to be opinionated on it also.

[00:17:17] Joe Colantonio All right, that's.

[00:17:18] Dalton Alexandre Yeah, I want suggestions from elsewhere as to how it should be shaped in the long run. Like I have the usefulness I need from it for now, and I don't need to add much more to where I'm then making suggestions that aren't beneficial.

[00:17:38] Joe Colantonio Cool. As a developer, is there anything that a tester you think should know if someone's coming from a testing perspective that they should know about mobile testing or look for when they're using in the Swift Appium or anything with Appium in general?

[00:17:49] Dalton Alexandre That is a good question. I don't know a great answer to it either. UI tests have limited functionality. They're not as apparent in their issues that unit tests bring up, but the comprehensive ability of a UI test is where there is benefit. The fact that the entire application is being tested at once. There isn't pieces that are independent from each other so much as the suite or the test that you're running is typically what the user sees. And it's from that, that we hope to find the bugs before customers do.

[00:18:31] Joe Colantonio So I assume you have a lot of unit tests. How does a tester know what's been covered and what's not? Like should it be a UI test for everything or is it, like you said, mostly covered at the lower level unit test and maybe have like an end-to-end flow test that just checks out from a user perspective of how it's working?

[00:18:49] Dalton Alexandre I know that there's different code coverage suites. Xcode has an ability to check the code coverage depending on what test it sees within your suite. But actually, I don't know a lot of the answers to the unit test questions just yet. There is quite a bit of it that is handled by our QA department that is separate from my current area with the UI automations, but just from what I've seen, I know we don't do a test-driven development, but that is a style of development that's fairly useful in using tests. But the coverage has its trade-offs in that you can get just as much functionality out of, say, 70 -80% coverage as you can from trying to reach that complete coverage where you're then writing tests that are essentially not performing anything.

[00:19:50] Joe Colantonio Maybe I'm old or I'm used to working in toxic cultures. Like my developers did not like to test. Like they would never run a unit test, never would have used Appium. Why, why test as a developer then? Why, why should you, why do you care? Or why did you get involved in testing?

[00:20:07] Dalton Alexandre Yeah. It's a lot like it's a safety rail, it's a guard rail against if you're in a car, you wear a seatbelt and that seatbelt is, it's there to ensure nothing detrimental happens and the comprehensive testing suite allows for better execution to where you're then not spending time fixing bugs rather than developing features that can then build off of each other. And when you know those features are good, then you can move on to the next feature. Having an untested application sent out to customers is dangerous in that you could be spending the next few weeks repairing any changes you've made. And so UI tests allow those changes to be made more apparent as they take place and allows the bugs to be handled before they're released into the wild.

[00:21:07] Joe Colantonio Nice, what is your code pipeline look like then? You're checking code to main, before it goes to production, do you have jobs that run your UI test first? And then if it passes, it goes to the next stage or is it something separate?

[00:21:20] Dalton Alexandre Yeah. Currently, we're using GitHub runners to pull GitHub actions. And so those are just simple YAML files that call for builds of the Android APK, for example, dumping that into a folder where the Appium framework then uploads it to the device when it That's a specific runner, but the runner that runs the testing suite is currently set up to the web, changes to the website. And when a new build gets sent to the development environment of the website, then the testing suite is RAM, which then looks, includes a look into that folder with the latest APK of the Android app. With iOS, it's handled through test flight, similar update process happens in the background, but the website uses the latest development branch when it's uploaded and the testing suite itself. I have manually been making changes to as it's being built.

[00:22:31] Joe Colantonio Another, I guess, distraction for developers is a lot of times people run UI tests and that they're kind of flaky. Sometimes they run, sometimes they pass, sometimes they fail. How reliable are your tests? Does it give you confidence to know as a safety net when they feel that I better listen because it's probably a real issue, not a some sort of flaky Appium issue.

[00:22:51] Dalton Alexandre Yeah, I'm not quite there just yet. These tests are still getting built. And when a change is made to the website, for example, we added a filter to how some feed loads are being made. And so that moved a button to a different location, causing my test to break. And I had to check with one of our managers to see like, Hey, is this known breaking point or is this just where I need to make some adjustment to my test? For now. It gives insight to changes being made that we're doing ourselves, but so long as it's consistent once it is running, then we're all pretty satisfied with the outcome.

[00:23:33] Joe Colantonio And that's a good conversation to have, like should this button have moved? It's not necessarily all the test is baloney because it failed, right?

[00:23:39] Dalton Alexandre Correct.

[00:23:40] Joe Colantonio Nice. Okay Dalton, before we go, is there one piece of actionable advice you can give to someone to help them with their mobile automation testing efforts? And what's the best way to find contact you or contribute to Swift Appium driver?

[00:23:54] Dalton Alexandre Build a simple screenshot test for your devices or for your application, if you have a personal project. I know UI tests don't get a lot of appreciation, but there is some usefulness that can come out of knowing the paths that your customers are taking when using your application and having that fine grain inclusion of functionality is important, I think. If you want to contribute to Swift Appium, it's available from the Appium ecosystem, but it's also hosted on GitHub, currently at the company organization Milc Group, M -I -L -C -G -R -O -U -P, and the project there is called Swift Appium. On LinkedIn, happy to connect there. I have been getting more involved with BlueSky. My handle is my family's dairy farm website alexanderfamilyfarm.com. And then my LinkedIn account is my full name, Dalton Lloyd Alexandre.

[00:25:03] Joe Colantonio Awesome. I'll link to these all as well as Swift Appium Driver down below. Check it out. Give it some love on GitHub and definitely give it a try.

[00:25:12] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguild.com/a537. And if the show has helped you in any way, why not rate it and review it in iTunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe, my mission is to help you succeed with creating end-to-end, full-stack automation awesomeness. As always, test everything and keep the good. Cheers.

[00:25:46] Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing, and DevOps. If you haven't yet, join our vibrant community at TestGuild.com where you become part of our elite circle driving innovation, software testing, and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit TestGuild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

[00:26:29] Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.