Swift Driver for Appium Automation Testing with Dalton Alexandre

In a land of testers far and widely journey seeking answers, seeking skills, seeking a better way O the Test Illumination Testing Podcast Guiding testers with our nation awesomeness from ancient realms to modern days, they lead the way. Oh the Testicle Ovation Testing Podcast.

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 or Milk group, which I think is a dairy ERP software. We'll find out more about it. You don't miss this episode when learn more about automation, UI Automation, Mobile automation, Appium Framework and a bunch more. Check it out all right, before we get into it, I want to give a big shout out to this week's episode sponsor Browser Stack App Live 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 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 local testing to test apps are required, access 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 dev tools for inspecting UI elements, monitoring network requests, and tracking app performance. BrowserStack app live offers a robust solution for mobile app testing that enhances productivity while assuring high quality user experiences. By providing access to real devices and advanced testing features, it 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. Hey Dalton, welcome to the Guild.

Hey, thanks for having me.

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?

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.

Yeah so I guess that was one of my first questions is why did you create this particular driver?

Yeah, I originally was developing iOS applications and had 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.

So it's interesting you self identify as a developer.

Yeah.

Why using Appium a lot of times people that are developers will use iOS native or other ways to automate.

Yeah. Originally the idea was to use the native espresso framework for for Android XC testing for iOS and then the the web test was where the 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 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 that's making it slow. Have you seen Appium is slower than the native frameworks?

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 some patience as does waiting for certain web pages, but some delay helps in structuring that. But usually when, when writing the test, I've yet to see any limitation in speed.

Great. So if people are familiar with Appium, how hard is it to get up to speed with Swift? Appium is there. How does it integrate as any tips on how to get up, get it up and running?

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, it's I've 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 could incorporate, that's definitely open.

So what do you mean it's bare bones compared to what you're using. So using it to do more awesomeness than what you release to keep it as vanilla as possible get started?

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 that in.

Nice. So it sounds like it's low overhead. What are any core dependencies that are needed for someone to get up and running with it?

No, Swift generally and I personally have been using Swift Testing, which is the new open source framework to integrate it. But the but an understanding of Swift and Swift Package Manager is useful in running it as an executable.

I actually haven't heard of Swift Testing. Yeah, is that a library for unit testing?

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 it's 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 are different type safety possibilities.

So what did you say it replaces?

X. Oh, Xcode XCTest XC test. So yeah, that's the unit testing typically done with iOS.

So why do you want to replace it? Because it's the same language as what are the reasons why you would replace.

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 unit tests you're able to paralyze all your tests to where a testing suite that usually took quite a bit of time can run much, much faster.

Gotcha. Gotcha. So are you using real devices or simulators to use this with?

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 limitations for myself in the server I was using that a parallelization of emulators was RAM heavy to where definitely had more luck running off of individual devices than spinning up multiple emulators at once.

Very cool. So why Swift? Is it because your applications ran in Swift and you just want to keep everything same code, code base?

Yeah, 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.

So how hard was it to start? I think a lot of people like oh I have this personal itch, I need an itch, I want to create this. How hard was it to create this open source project and contribute to the Appian project at large?

Not very difficult to begin with. I had a discussion with my boss in asking if this was all right, like what parts and pieces were I was able to share. But then in discussion with Appium was as simple as a pull request with the ideas of including some Swift code and they were all very receptive and and lined out parameters for me 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.

Nice. So were there any challenges when developing Swift Appian? It sounded like documentation was hard to come by. I don't know, was there anything else?

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 the knowing what I wanted to accomplish was also the difficult part. Most of the interaction is through the WebDriver 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 webpage 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.

Why is that? Just because Chrome probably has better support?

I think so, yeah, initially and Appium is in a new it has gone through a new update and I don't know if Safari the Safari driver is completely up to speed with some of that.

Nice. So 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? No Brad the client?

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.

Nice. So have you gotten any feedback from anyone yet? I know it's very, very.

It's Fairly new so one star on GitHub so far. Thank you.

Hey, you need one to get get to many so that's good. 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 SwiftAFTA and people should try it and give it some love on GitHub?

Yeah, there's definitely usefulness in 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, 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 look, review and merge. It's a great feeling as well as it adds to your ability as a developer in so many ways. And learning how they want their project structured teaches you a lot about how different code bases work as well as defining techniques that you can definitely take elsewhere.

Very cool. So someone's listening to us. They've already used Appium, but they haven't used the Swift Appium. How hard would it be for them to get started? What would they need to do?

Some understanding of Swift is useful and setting up a test is the first role where you have to communicate with the client. So 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 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 in 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.

Nice. Once again, you said you started off as bare bones. There's a reason why you started as barebones is because you wanted people to contribute or is it because you just wanted to start as quickly as possible and then start merging in all this other stuff that you have that maybe isn't quite ready for prime time?

Yeah, I don't want to be opinionated on it also.

All right, that's.

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.

Cool. So, you know, 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?

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 they're. Before customers do.

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 an end to end flow test that just checks out from a user perspective of how it's working?

Yeah, I know that there's different code coverage suites. Xcode has the 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 the 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.

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 have run a unit test, never would have used Appium. Why? Why test as a developer then? Why, why should you? Why do you care? Why did you get involved in testing?

Yeah, it's a lot like it's a safety rail, it's a guardrail 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 a 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.

Nice. So what does your code pipeline look like then? You're checking code domain 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?

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 the Android apk, for example, dumping that into a folder where the Appium framework then uploads it to the device when it runs. And 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 ran, which then includes a look into that folder with the latest APK of the Android app. With iOS it's handled through TestFlight. A 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.

So 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? Where 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.

Yeah, I'm not quite there just yet. These tests are still getting built and when a change is made to the website. So for example, we added a filter to how some feedloads 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? So for now it, it gives insight to changes being made that we're doing ourselves, but so long as it's consistent once it is running, then then we're all pretty satisfied with the outcome and.

That'S a good conversation to have like should this button have moved? It's not necessarily. Oh, the test is baloney because it failed, right?

Correct.

Nice. Okay Dalton, before we go, is there one piece of actual advice you can give to someone to help them with their mobile automation testing efforts and what's the best way to find contact or contribute to Swift Appium driver?

Yeah, build a simple screenshot test for your devices or for your application if you have a personal project. I know UI test 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 their company organization Milk Group M I L C G R O U P and the project there is called Swift Appium on LinkedIn. I'm happy to connect there. I have been getting more involved with bluesky. My handle is my family's dairy farm website, Alexander Family Farm and then my LinkedIn account is my full name Dalton LloydAlexandra Awesome.

We'll have a 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. Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on 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. 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. 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@testguild.com where you become part of our elite circle driving innovation in 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.

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 tester showing the secrets to behold.