Unveiling the Potential of XCUITest and Espresso with Igor Dorovskikh

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast and today we'll be talking with Igor all about mobile testing, specifically about Polyx UI tests, Expresso and all things automation awesomeness. If you don't know, Igor is the accomplished CEO and founder of Ingenius IO, a leading mobile consulting startup that caters to top tier clients. He's worked with people like Apple and Grammarly, he has almost 15 years of experience in mobile development and he's an accomplished author and authority in this field with a focus on building world class engineering teams that deliver mobile apps applications. I've met with him multiple times. We've met up at Selenium Conf. He's working on a lot of cool things. He has some open source projects he's been working on, he has some education things he's working on that he'll be unveiling shortly. So a lot of experience. He also works at a lot of or used to work at a lot of top Silicon Valley companies like I think worked at Barnes and Noble, Expedia, Tinder and he's played a key role in driving mobile release management, mobile DevOps and quality processes across multiple companies. And he's a guest speaker at multiple conferences as well. Really excited to have him on the show. You don't want to miss this episode. And also I'm really excited to let you know he's going to be doing a 90 minute workshop at the 2024 Automation Guild. And to check that out, head on over to automationguild.com it'll be released soon, a registration will be open soon, so you definitely check that out as well. You don't want to miss this episode. Check it out. This episode of the Test Guild Automation Podcast is sponsored by the Test Guild. Test Guild offers amazing partnership plans that cater to your brand awareness, lead generation and thought leadership goals. Get your products and services in front of your ideal target audience. Our satisfied clients rave about the results they've seen from partnering with us. From boosted event attendance to impressive roi. Visit our website and let's talk about how Test Guild could take your brand to the next level. Head on over to test guild.info and let's talk.

Hey Gur. Welcome to the Guild.

Thank you Joel. Thank you. I'm Thrilled.

Awesome to have you. It's been a while. I've been wanting to have you on the show for a while. I don't know why it's been. It's taken me nine years but. Welcome. Excited to have you. Before we get into it, you are. Is there anything I missed in your bio that you want the Guild to know more about?

No. It was amazing bio. Probably one of the best intros. Thank you Joe. I think you said it all. I've been in testing community for a long time. Test automation was a big thing before a lot of people thought about this or talk about it's in mainstream and even up to date running the company which is a mobile first company. Right. We do not just test automation testing but also mobile development. I'm a huge evangelist, big fan of yours and I'm still in the industry of testing and test automation.

Love it. So you have a really interesting background. Just curious to know how you got into mobile testing because you've been there for a while and you're one of the first people that actually I know that really started innovating in this era. So how did you get into mobile automation testing as one of your real specialties?

Yeah, thank you Joe for this question. I think that it just happened naturally. My first internship was mobile before iPhone and Android era on if you remember Symbian J2ME platform platforms back in 2006, 2007. So I got into mobile before what people actually talk about mobile, right? And back then we even automated on those platforms. I work on a startup who was building the SDK for Eclipse to build the applications for J2ME phones and Symbian phones. So we were writing automation even before people talk about automation. And naturally I segued into the Android first because Android was more mature than I as if you remember 2008, 2009, those brick, you know, G1 phones. So I started automating with Robotium back in 2008. 2009 because instrumentation actually 2009, 2010 because instrumentation that shipped with the original SDK wasn't usable as a framework for automation. So Robotium was the thing. And then around 2012 slowly moved to the IES automation. There was a framework that used to be called Frankenstein Frank. So yeah, and then I met Jonathan Lips at the conference in GTAC 2013 and he convinced me to use the pre release version of appium. And from 2013 until 2016 I was a huge SaaS lab evangelist walking through different conferences internally and externally, like you know, like Facebook, you name it like Visa and talk about Appium and how great it is. And 2000, around 2015 after espresso framework was released, I started preaching about Espresso. I think Valeri did a great presentation 2013 but it still wasn't open to the public. But 2015 I started converting. Back days when I work at Expedia would start converting from Appium to Espresso and then 201617 Xua test. So I lived through entire transformation, you know, in the mobile space of test automation. Quite a journey.

Yeah. Love your background. So why leave Appium? Any pros and cons of when someone should use it before we dive into some other solutions that may be a better fit for certain companies?

It's a great question because a lot of people ask this. Not only people, customers ask this question, you know, when should we use one over another? And the answer is it depends on the problem you try to solve. As of today it's a crystal clear if it is native, if the application built natively like using the iOS stack or Android stack, definitely use native solution. That's the way to go. I spoke with a lot of folks, got a feedback. Appium is really flaky if you go native, like probably 80% of the best shot. However, if the app builds as a cross platform using frameworks such as React native, then I think Appium is indispensable. So I, I would personally use Appium for cross platform applications.

Absolutely. So normally when on the podcast and when I go to conferences, you always hear about Selenium and Appium. Not so much about actual tests, maybe sometimes, but even less about Espresso. Why do you think that is? Or Judictors? Is there a big community around Espresso? Is it just something that's so niche that maybe that's why you don't hear about as much as Selenium or Appium.

I think that's very good question. I think there's several reasons for that. So number one is the verticals, right? It just happens to be that from the Selenium era, right. When the Selenium became popular in 2011, 2012 was the Selenium Webdriver 2.0. A lot of manual testers start converting to DOS automation via that and that segued into the Appium. So a lot of management, and that's the thing that I'm going to focus on management made a decision to build horizontal expertise and test automation for the teams where they take a test automation engineer or SDAD and say okay, now you do web mobile. I Guess Android backend, you name it versus the.

So this is verticals, right? So similarly for development, have you ever seen a developer that works on IAS development that does Android probably not similar and vice versa, right? For the ies. So I think that the reason those topics are not spoken, you know, the conferences and widespread is because it's expertise in one area. So in my perception, because I've been teaching that topic also for a long time in our boot camps in our programs over course of right now, 10 years I've noticed that the best SDADs for the, you know, I S or Android are those who are come from a development background. So in my experience the best conversion it would take like fairly technical person like a junior IAS developer. You can convert them quickly from the qa. They have to learn the platform itself, right? But however the power of, you know, actually test espresso way more, you know, in terms of the impact than you use cross platform solutions. So it's about expertise and domain knowledge. I think that's the key. And management usually make decision to create like a cookie cutter approach, okay, let's just build the universal soldier who will do everything instead of build the verticals. I think that's the main reason.

So when someone is in a vertical who tends to do the testing then is it mostly the developers that are using actual test in espresso or like you said, because you do need some programming language, do testers get involved later on? How does that normally work?

So normally, normally if the management makes the right decision and put a dedicated person and with reasonable goal, say okay, for next year, you didn't do anything else but let's say IAS automation, nothing else. So you have to focus on one platform. We're going to touch you so that person becomes, you know, knowledgeable in that platform. They work with development. Don't forget that all the source code for test when you automate in the X test or espresso lives in the same code repository as the application under test. Which means that they will naturally work on the same environment. DPRs will be popped out for developers as well on that platform. They talk the same language. So usually the person develops with the team. An amazing side effect that I noticed is it's amazing one folks who work as the SDAD on either iOS or Android vertical automating those native solutions about after one year get converted to developers. But they have the main knowledge and they sustain the framework, not only the tasks but infrastructure. Because besides testing, you will have to work with a test ops Infrastructure for that native thing. So that's how usually these people build up. So it could be a very solid test automation engineer, come from web or backend, it doesn't matter. But they have to stay focused on one platform for a long time. So not necessarily developers, but I've seen teams where developers get tasked to support those tasks. But that's very subjective because I mean developers have to spend a lot of time to build features, fixing bugs, and that's why the ask that role exists. Right. And then we recommend the companies don't mix those roles. But I've seen companies that successfully implement this. It's doable, but that's the reality of today's, you know, world of software development in the mobile space.

So, Igor, I think I forgot to just set the stage before we dive a little more deeper. I just assume everyone knows what X UI tests and Espresso is, but I'm not sure. So let's just define what is X uitest and what is Espresso before we dive in anymore.

Yes, it's really simple. Xuitest is the library that ships with the xcode. So when you download Xcode for IIS development, it's already part of it. You don't have to install anything else third party. It's just an additional library for writing UI functional tests on top of their exit test libraries, extension of exit test library for unit testing. So you use it for writing functional tasks for all variety of Apple products, not just iPhone. You can write it for Apple Watch, you can write it for Apple tv. And we actually have clients who do for Mac OS X as well. And in terms of setup, it takes, we actually did measure that. It takes under one minute to set it up. Just a couple clicks and you're good to go. So in terms of Espresso, similarly to the X UA test, it's a library that ships with the Android SDK. So when you download Android Studio out of the box, you need a couple of things with a Gradle setup. And Gradle is for those folks who doesn't know what Gradle is, just a wrapper on top of the Maven for Android. And it takes literally like a minute also to set up the Espresso test. Espresso is just the library they have also UI automator. So it's not only one testing library that ships with the Android SDK and both frameworks are used for native Automation of native IaaS and Android applications. Extremely powerful. You can do a lot of things like that, you know, Appium Cannot do physically because Appium mostly is a black box automation. So you can like write own interceptors, you can launch isolated activities like a screen, you can put the application certain state, you can test client analytics and you can control a B test from the inside app, which is why it's so powerful. So those are framework in a nutshell. That's what they do.

Nice. So they tend the tests, do they tend to run faster? It sounds like you could set them up quicker than maybe someone style would Appian. But how about speed wise of these tests because they're native, do they run quicker or any other benefits?

Absolutely. And that's why I recommend when go native try to use native frameworks for exactly reasons you mentioned. Speed is the big thing. I mean when you have like 10, 20 tests it doesn't matter, right? But when you have thousands, it becomes really matter. Especially when your management tried to run it every PR merge. So every like commit. So you want to trigger all this test so you cannot run them for hours. So yes, the biggest benefit they are fast and don't. I mean when people talk About Appium, Appium 2.0, today's Appium, right Is a wrapper around those frameworks. So under hood there's still those espresso and X UA test. The Appium is just a wrapper around those native frameworks and so you still kind of use them under hood. But don't forget about Appium architecture. It's a node JS server, right? So it creates extra layer of complexity and also creates extra layer for flakiness. So basically you remove that extra layer uses natively, right? So yes, speed is going to be big difference. Another thing is orchestration and stability because you have full control over application under test. And like I mentioned, it's more like you can do more white boxy things. You can do like things that you cannot do with Appium. And I just mentioned those examples like for instance deep linking, right? Or put application certain state or mocking, right. You do not have to write a separate server for that. You can mark them right on the spot. So just a few examples where it's so powerful so and a great example, a lot of clients asking to compare Appium because they're already using it with native solutions. So I mean I'm just saying this number is not because I just want to show off or just bring. This is a real numbers you can if you doing the right thing. If you write a test with a good architecture in mind and using the best practices with X UI test express you can achieve 98% stability. It's very high. Why those? Why not hundred percent. Right. Is because there's infrastructural things you cannot control, right? And that becomes a more Test Ops DevOps setup. But from the test perspective, you can achieve 98% fairly easy with native solutions.

Pretty bold statement. So is this from experience or this is like something just you've seen over your career when you work with clients like go and get Appium versus I'm not saying one's better than the other, but just say in general, why are they more stable though? Is it because people don't know how to write correct Appium test or it's just because it is native that it's in the ecosystem so it tends just to run smoother and more reliably.

Both what just meant? I mean I understand it's very bold statement, but again I speak out of my experience. I teach this thing, I talk to a lot of students, I talk to a lot of people from various companies. For the matter of fact, just came back from Taskcon where we do the workshop and folks, I asked folks who's Appium was there stability and they say roughly around 80%. So 20% flakiness, that's the reality. I mean, but native automation, how you can achieve this? Absolutely. Don't forget you are working on the same toolset as the developers, right? You are very close to that. A lot of apps not automatable, right? You have to make the app automatable because you work on the same stack with them. You can do that, you communicate the same language with them. That's one reason. So you can influence the app to be more stable and be ready for automation and add necessarily hooks like accessibility identifiers or content descriptors. And you can do that. You can do it on your own. Not only mention this, there will be automation reveal the bugs that manual testing cannot reveal. And again you speak with developers. That's one way. Second is because it's native. As I mentioned, Appium create extra complexity because it's a server run. It's a wrapper around this. So you remove all this noise so you can use like, you know, parallel test execution. Much more faster than use like Selenium Grid with Appium like architecture, right? Which basically cannot be very fast by its nature. So again, I'm not just saying that Appium is a bad tool. No, Appium is amazing tool, but for right reason if you ask me today Igor, what would you choose for cross platform testing? I would go myself and do Appium which is better. But natively to achieve that 98% stability, you have to use best engineering practices and follow those protocols. It's not like you gonna by default if you write X UI Testospresso test, you're gonna get 98% stability. No, you have to follow best practices. Like one of the great example is network mocking or they call stubbing, right. Without those things you will never achieve that stability because backend by itself can undergo multiple deployments per day. Backend can have hundreds of a B test experiments. How are you going to control end to end test? So by writing tests that are hitting the backend. Even axioa test or espresso not going to give you this 98%. However, orchestration is going to be very important thing.

So Igor, you mentioned network marketing a few times. Maybe could you give us a little heads up on best practices or ways you maybe see where people don't leverage network marking and how they can and what it can really help them with?

Yeah, I mean usually when we talk about network mocking, right. That the whole terminology came from development, right? That's where when developer write the unit test they have to mock everything. And that's what actually gives the unit test so much stability, right. But when we come to the test automation for functional test automation, right? And when it comes to the test automation engineers and they hear this phrase network mocking or stubbing, it just give them a good skin. They're like OMG what the hell it is right? What should I do with that? So I think that comes with the background of most test automation engineers because they're not coming from a development background, they come from a testing background. I think this just spooks them off. But network mocking out of the box for Android, right? It ships with the mock HTTP web server, which you can do. This is another library, basically what you do, you record, you know, server responses and you alter them. You don't need like to have gigantic responses from the back end and store them locally. And when the app actually hits that request, it redirects them to this fake data. So this way you always have the same outcome. So let's say that if I use application like a chat app, I always chat with Joe, not anybody else. And I always get hello world. So I know exactly what the application going to return. Which is actually brings another question. What about end to end test? And that's where manual tests are supposed to be, right? So we are testing the Android or iOS app in isolation or like in hermetic we call hermetic testing. Right. Backend should be tested by the backend test like API or microservices and that's how we know that those tests are actually finding the front end bugs, not the backend bugs. So mocking is very essential for test stability and speed because we completely removing the drone trip from request response. And a lot of people ask me like what about websockets, can we mock them? Yes. Google protocol buffers. Absolutely. It doesn't matter. We can mock everything. Right. But there are different tools available. There's third party solution like sbtui test tunnel for I has been used for a long time. So what we did in Enginius we built our own solution like a VCR recorder, if you remember those from back days. Right. Which is basically a proxy which let all the, you know, requests come through but next time it redirects to the fake data. So we created this, you know, very easy, very like lightweight mock web server which is helps to eliminate the fear from this test automation engineers and help them to ramp up to the ass. That's pretty quickly instead of like sitting and trying to understand like how the backend works, what the response schema is supposed to look like and use the Charles for that. Right. So yeah.

What's the name of that tool?

So that's it. We're not open source it yet.

Okay.

We just use for internal clients.

Gotcha, gotcha.

But we are planning, we are planning, we are planning to do something about this. We're not sure yet internally so far we use it mostly for our students and for our clients but we haven't open sourced it yet. However, I will give you a links of the open frameworks that you know available and you can share with the community in. Down. Down the video. Right? As a links.

Yes, absolutely. So I'll have that in the show notes for sure. People should definitely check out. So besides network mocking, you mentioned orchestration for some reason I assume orchestration would be easier with Appium. But is orchestration different when you use an X UI test or espresso and if so, what do you use to make it more seamless or easy?

Can you elaborate on orchestration? Because orchestration, it's a very broad term. Right.

Just running test in parallel or across multiple devices really quickly I would say.

Okay. Because a lot of people mean different things when they talk about orchestration. In terms of. Yeah, in terms of the test execution. Absolutely. So we build ourselves open source solution for that because we back in 2019 when we started getting our first clients for consultancy, we couldn't find one. We tried to use bluepill, we tried to use few others but nothing worked out of the box. So we built called Sift. Again I'm going to provide a link. It's on the GitHub, it's open source, completely free. So Sift built for both iOS and Android and it helps to run tests in parallel natively. Right. And it's very configurable. It has the rerun mechanism in it. You can add nodes, as many as you need and it you can build even autoscaler. So basically the more tests you have, you just add more nodes and it's gonna run in parallel and it's super fast and very stable. We use for existing clients. That's how we continuously updating it. We got a few community members who started using that as well and we run a discord community where people come join us and ask questions and we'll help them with the setup of the cfts. But there is not like when we talk about enterprise setup when we have like for instance one of our clients is Apple and they need thousands of tests. Right. So for that reason there's a very different DevOps and Devs ops involved lately we partner up with the company called Marathon Labs. There's a lot of companies you call Lambda test browser stack, SaaS Labs. I mean I'm not going to head spin. You probably had all of them on your show.

Absolutely.

But you never had a Marathon lab.

No.

So who are these guys? Right. I completely randomly met them. Oh, you probably heard about Case IO, right? Nikita, I think you had him on the SHIELD show.

Yep.

So he introduced me to this folks. So this is just a bunch of very smart engineers who try to solve the problem of enterprise level test execution for native tests for IIS and Android. So they don't do web, they do only native. And their one liner kind of advertising is no matter how many tests you have running them under 15 minutes, I was like no way. So I tried them, I POC'd them and they do it. So they're very crazy DevOps setup and they actually run thousands of tests under 15 minutes. 1:5, not 50:15. So we partner up with them and they are doing a great job. One of the co founders of them I think Rolled Kaspresso is a wraparound espresso. He is there as well. Very smart guys. And again the broad expertise natively I think they built Android first and IES next and when we need to go for enterprise setup like test orchestration, we use them. If it's a startup, it's overkill, you don't need to use them. So we use the sift and just set up the local, you know, environment. I mean local doesn't mean like a physical Mac Minis. Right? We're talking about like some cloud, like aws. Right. For instance.

Let's actually start a demo of this at Selenium Conf. You gave me a quick overview. Seemed really cool. It supports real devices as well, I believe and has a reporting system. Has all these cool things built in for free.

You talking about Marathon Labs or you talk about whom?

No, Sift.

Oh Sift. Yeah, we support everything. Yeah, Sift. Yeah. We actually presented TestCon in Vilnius recently. We support this for right now, four years. Yeah. And it's very scalable. I mean there is no boundaries there. It's support by the way also macOS, you don't need it to iPhone support physical devices, emulators and you can scan vertically and horizontally. No limits. Yes.

So I guess another maybe stumbling block for some people that are testers testing focus. Are there any resources available maybe to beginners to learn X UI tests or espresso? And how steep is maybe the learning curve compared to say Selenium or Appium?

I wouldn't say it's more steeper. I think it's more. You have to be more focused. So what I recommend people who decide to go to that route. I mean you have to have some sort of a plan, right? You cannot just go like without the plan and the plan has to be follows. Do you want to become eventually iOS or Android developer? If this is the plan, if you're thinking that in the near future, two years from today, one year, three years, doesn't matter, you want to become iOS or Android dev, that's number thing you have to ask yourself because what happens again, I just noticed this over the course of, you know, past five years. All assets that we try to convert or build, they eventually become devs. It's just the reality. If you want to go that route, then yes, absolutely. In terms of learning curve, you will probably have to dive deeper in IAS and Android development, which is not hard nowadays. I mean Kotlin and Swift are very easy languages to learn, not harder than Python. They actually use some Python elements in them. And JavaScript is very. It's not Objective C and Java, right. Which used to be, if you remember Joe, like nightmare, right. To learn back in the day. But yeah, Swift and Kotlin are fairly simple. So learning curve is not steeper than you do for Web like using playwright. But what you will encounter is learning at the main knowledge of the platform. That's going to be the key. That's what their whole time. So you are going to learn how to automate tests pretty quickly but it's going to take you probably close to one year to get familiar with the platform. And again every app is unique, right? There's no like you know, all absolutely the same. Every app has different architecture use different libraries. Also the every team has own culture. So you basically live in that culture, right? You're willing with the you talk going to talk to iOS developers every day or Android developers. Coming back to our original question, what are the learning resources? So not that many to be honest. I mean there are a lot of for the beginners just to jumpstart yourself like I know that Test Automation University by applitools they have intro courses they're a little bit outdated but they're good enough to jumpstart. Also both Apple and Android have like recently by the way Google released a very nice course for Espresso completely free. Besides that if you ask about like external resources. I like coding with Mitch. You probably heard about this guy coding with Mitch. He's a big evangelist on Android development. He has two comprehensive courses on Android Test automation with Espresso. That's another big one. However there's not much like enterprise level for X UI test. So that's why restarted our university ingenious University in 2023 and we build a comprehensive. We spent more than a year and six engineers work on the course for this enterprise level setup X UA test. So we have them available right now on our educational platform and next year we'll try to do the same thing with Android Espresso. But to be honest like for the beginners there's few resources but to go like in depth like enterprise level setup like mocking or test architecture because IIS development page object model not going to work. It's not you know standard architecture do for web because Swift is a protocol based programming not object oriented. So there is a different approach, different architecture. So similarly to like Android use robot framework, right? Not robot as a testing framework but robot pattern. So it's all doable. In my experience it takes on average like six months to get from zero to a person who completely write test and then about year experience on top of this. But again what is your ultimate goal? You have to ask yourself.

Absolutely. So I have to ask you this. Just getting your perspective on where we're going with mobile testing specific to X UI test and Espresso. As you know, AI is the buzz. Every solution I speak with nowadays for the web they have like colist solutions that automatically will write the code for you similar to Copilot. So does this help you learn X UI tests in Espresso better because it could write the code for you is do you see solutions coming out for mobile testing that leverages AI that you probably see? Maybe if someone was to dive into X UI tests and espresso, they're going to be not of a job but out of date or like not it's going to be easier to get into because you'll be able to leverage something like AI machine learning.

Yeah, it's very modern question I would say and up to date, not so obvious and not so straightforward for the web. So I think AI found itself very well like at the at the moment we're talking about right now that you can generate a baseline test for the web much quicker using AI like Chat GPT for instance. Right. Declarative AI. But you see that how I envision today's like version of AI, it's mostly like your smart body that you talk to. We probably heard it many times. You have to still digest that information and make a rational decision if it you know objectively it's right or wrong. If you don't have the domain knowledge, how are you going to make this decision? How to know what it's actually gave to you. But the answer to the direct answer to your question is it's for the native apps. Definitely not so easy. As for the web, we tried it however you can ask questions to build your examples like for instance, you try to battle a problem and you need Google answers. So if you ask ChatGPT we'll give you a couple examples that can put you on the right track for the solution in that way. Yes, but not going to write those tests. However, where I see AI will be, I mean AI is when AI is just like you know, artificial intelligence, machine learning. We're going to go get us to is more like what applitools does for the UI testing. Not functional, not flow, but UI visual testing. Because now I think we can educate systems what is right or wrong, feed the data and we don't need to do this image like you know applitools does like base screen on top of the new screen. I think those type of tests are going to be gone like sooner than we think and I think that's what applitools going to deliver. I sense it. I don't know I'm just sense it that that's what they're going to deliver next Functionize applitools birthday. I mean all these similar like competitors. I think it will be a huge breakthrough in the UI validation but functional automation wise go through the flows. I still will be there for the foreseeable future, maybe two, three years then I don't know but again why I recommend people and whom I recommend people to learn these native solutions is that if you want to become experts in that platform, become really good at this. One of a kind, it's niche but think about this. Here's my iPhone right? That's what you probably use every day for everything like so think about this. Yeah that's that's always like you want to be expert in this and you will be desired as an expert in the industry and a logical step you will become developer. I mean it's very subjective like you know, maybe answer but the best I could.

Awesome. Okay, 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 or contact you?

Yeah, my piece of advice that again that comes from experience. Please don't jump from one chair to another. Stay focused. Right now even more than ever before, there's so much noise. People talk about AI and you hear Joe on your talk show, you can get scared pretty quickly, you can get confused and paranoid. Just stay focused and pick up one domain, pick one vertical and become really good at this at least for one year. Don't change your mindset even if you and you can actually make the, you know, a case, a use case for your management. Say hey listen, I want to be good and I will bring a huge benefit to this. So stay focused and become good at one thing regardless. That's my piece of advice and how you can contact me. LinkedIn, I'm there. And also we run a discord community, complimentary, completely free. I brought in more than two dozens right now, experts in the native test automation test automation management to help folks because right now, like I said we try to help community. Right. And I'm going to share the link with you Joel so you can share with the community and then come with the questions anytime and we're going to get you, you know, your answers regardless and we put it on different verticals web native backend development so you can find your niche there. I think that's the best way to talk to me at any time.

Awesome. And a quick plug if you want to get up to speed on X UI test and espresso. You definitely want to check out Igor's 90 minute workshop that's part of the Automation Guild that's going on in February 5th to the 9th and you can definitely check that out by registering@automationguild.com. thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a474 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. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the guild community, I'd love to hear from you. Head on over to test guild.info and let's make it happen.