Scaling Automation Using 7Facette with Patrick Döring

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. And today we'll be talking with Patrick all about how to scale your automation using 7 facet. If you don't know, Patrick has been a passionate quality engineer since 2008 and a chief architect for test automation automation since 2019. So he really knows his stuff. And besides that, he also really excels at technical leadership. He's also responsible for mentoring and growing his colleagues to help them improve their automation testing skills as well. And Patrick has always made it a priority to maintain a close link to the research community to evaluate and implement innovative advances in information technology. And I think this is what he's achieved in 7 facet with a lot of different things that I've never touched before and I'm really excited to get into it, so you don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment for Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out. Hey Patrick, welcome to the Guild.

Hey Joe. Nice to be here.

Awesome. Great to have you. You've been on my schedule for a while, so I've been really excited about this episode. Before we get into though, Patrick, is anything I missed in your bio that you want the Guild to know more about?

No, I mean everything was in my bio, I believe. Let me think about. No, everything was in it. Yeah.

So there are a lot of things here that I'm kind of new to, so it's going to be kind of like a beginner level type of. What's this? Why did you do that? Type of episode? I think and the first one is seven Facet and I know it's an open source solution, but can you tell me a little bit more about what is 7 facet?

Yeah, 7 facet is a test automation library written in Kotlin and we implemented as multi platform project. So we can compile the functionality for JavaScript and Java and we can reduce duplicate code with that. So we have to implement the stuff twice in two different languages. We can only implement our stuff in one language and get the compilation out of that. And that makes it very, very Easy us to use that library or the functionalities in different kind of teams and in different kind of projects again and again. Because every member of a team knows the function in JavaScript and also knows the function in Java because they should be the same so that you call the methods and the parameters, it should be always the same. So at the end you can decide or your project can decide, hey, I want to take JavaScript because my devs are very good in JavaScript implementation and can say okay, we want to implemented in JavaScript and if somebody switched a team or I don't know, the project changes to a Java language, they can change to Java back and can say okay, we can implement the same stuff in Java because we know the methods, the implementation is, it's, it's like the same. That's the cool thing.

And is that why you use Kotlin? Why would you use Kotlin to give you that, that ability to use different languages behind the scenes?

No, why we use Kotlin it comes from a colleague from mine. He comes up with the idea, hey, we could write our automation code in Kotlin and here we have to know the history of us because we started implementing our automation library in Java and he comes up with the idea, come on, we can write it in Kotlin. And after some research we found out, oh, ChatBrands offers this opportunity to write a multi platform project to implement stuff in Kotlin and we can use that and JavaScript and Java. Okay, let's give it a try. We want to know that. Yeah, awesome.

So that's one of the benefits for sure. So you mentioned it works with Java and JavaScript and I guess it's something that's happened on the back end. So someone doesn't know as a user of it whether it's implementing Java or JavaScript is how it works because you have functions and parameters that are exactly the same regardless of what language is being used on the back end.

Yeah, we try to implement it as good as we can to really use the same parameters but we have situations where it's not possible. Okay. And the implementation is crucible I would say but okay, we should always think about the multi platform project from ChatBrains is in an alpha state. So not everything is perfect now. And for that we have to think about can we implement this or do we have to implement such kind of workaround that's not always the same. Okay, it could not be perfect at the moment but the most things we try to make it very, very comfortable for our devs to use that. That's the important stuff for us.

Nice. And because it does work with Java and JavaScript, does that mean at some point in time if you have people that contribute, you could have a Python implementation and a Ruby implementation, or is it just Java and JavaScript?

Actually, yes. I also read about Objective C, but I'm not pretty sure if I really want to implement that. I would say for us as a company, it's enough to bring up a version for JavaScript and Java because the most project from our company working with JavaScript and Java, we have less Python projects. But yeah, we could think about if we implement a Python stack, but that could not be implemented with Kotlin at the moment and it's not planned at the moment.

Gotcha. So is this like a library? Like any other library you would use in either Java or JavaScript, you just import it and then just start using it?

Correct. That's one of the important points for us. You only have to add your jars or your dependency in JavaScript and then you create your configuration file, which is a YAML for Java or JSON for JavaScript. And if you're ready, you're up and running. So you don't have to do anything. You can write your automation code in that and then you can call your REST APIs or GraphQL APIs. You can make your UI automation actual selenium. But we plan to switch to Playwright. You can interact with your database, you can interact with an Apache Kafka. So it's always on board. Yeah, you don't have to think about, oh, how do I implement my Kafka consumer and producer for my testing anymore? Because it's already there, you have to configure it.

So that's what's kind of unique about this solution. A lot of people like, why another framework? Most frameworks just, I think focus in on UI automation, but this sounds like it handles a bunch of other things. Let's start with the UI automation though. First, you did mention it is using Selenium currently, but you plan on moving to Playwright. Will people have an option to use either or is there a reason why you think Playwright would be a better option for this particular implementation of your.

Framework at the moment? There are two main reasons. The first reason is Playwright did a really good job in the last months with the releases. They are very fast, they bring a lot of interesting features up and that works really, really well. Pretty good, I would say, because that are the same devs from Puppeteer and Puppeteer was really, really fast. And that's the same for Playwright, but it seems more. More completely. And the other reason is Playwright goes the next step. Like we, we try to be platform independent, so we want to try to implement JavaScript and Java stuff. And playwright implement also JavaScript, Java and. And of course C or. Net. Actually we only need the Java and JavaScript. So that is the right direction for us to be platform independent. And if we want to implement a Python version from 7.4z, then we also can use Playwright out of the box there. And that's awesome. And I solved the problem to run playwright on AWS in a lambda function. So it's pretty easy without changing any browser or jaws on that. So we can use Playwright out of the box and that's cool.

You actually have a really good blog post on actually implementing that running test in parallel. I think you said using playwright with 7 facet against AWS. So let's dive into that because once again, I'm kind of new to serverless, kind of new to lambda. If other people is first time them hearing lambda functions like what is a lambda function? I think we probably need to determine before we get into what you did there.

That's awesome because I'm also really new to lambda functions.

As I start with lambda functions, I read the first 30 sides of this book.

Oh, that's awesome.

And I thought, awesome. I have to read 30 sides of this book and I have my first function up and running and it works. Okay, cool.

But I would describe lambda function from my side like that. I would say you don't have to babysit your server anymore so you can run everything in a function. You have to play by the rules from Lambda. Okay, but at the end you don't have to care about the server and infrastructure under the hood, what they mean.

By serverless in the sense you're just running functions and the function then handles all the infrastructure type thing because it's docker like in a Docker container or something.

It seems for me, it seems at the moment, it seems I'm not as deep in serverless at the moment, but I tried to make one step by another. The first thing was I heard serverless. Okay, let's give it a try. Can we do it? Can we use that for testing and test automation? That was my first intention on that as I read this book. And yeah, I wanted to give it a try because it must be possible, I thought. So I wanted to see if we can do that.

So as I mentioned, you did write a blog about this did it allow you to run tests faster and in parallel more using this approach?

It's really fast. For example, we had an execution time from 50 minutes before and now our execution time is one and a half minute.

Get out of here.

And the cool thing is, Joe, the cool thing is we didn't change the testing code for that.

Wow.

We only used the same template from AWS and copied our testing code in the template repository. And that's it. And after that you can run your tests in parallel. You don't have to configure how many threads do you want, how many cpu, how many memory? You don't have to care about it. You can write your tests and at the end you say, okay, let's trigger my test via easy rest call and the lambda scale out by itself and you don't have to care about. And that makes my work and my execution time very, very comfortable and very, very fast. I would say, because I proved that I can run my end to end test with UI, with API and so on in one and a half minutes instead of 50 minutes. And I think about bigger scenarios about what happens if I have 300 test cases. I mean I can run 300 test cases in parallel and I got the result at the end after I don't know, one minute, two minutes. But I have 300 results there and I can scale out it until thousand functions out of the box. And I would say if we talk to AWS, it's possible to run more functions in parallel. Like 60,000, I don't know. But that's an interesting scenario because I don't have to care about. And that's awesome. That's really awesome.

Yeah, I mean I haven't done, I haven't worked for a company in a few years now doing hands on. But this is definitely the approach I would definitely, first thing I would try because it sounds like it's really working. Is there any downside to it? Is there a cost? I assume there's some sort of cost associated with it as the amount of functions that are consumed or. I don't know how that works.

But the first downside was how can I get runded? I tried a lot. I started, okay, how can I call a lambda function? Okay. Then I tried with the book, okay, you have an easy lambda function, come on. And it's working fine. Then I thought, okay, my test automation, how would I bring my test automation code, my test cases up to a lambda function and then okay, hmm, it's not as easy. Ah, Lambda AWS Lambda offers this opportunity to upload Docker container in the ECR and so on. And then I thought, okay, great, I won the game. I can create my Docker container, I can push it up in the ECR repository. Okay, it seems pretty easy. And locally it runs in, I don't know, five minutes. And I thought, okay, cool, I'm done. And then there comes the downside. I uploaded everything. And I thought, okay, come on, Lambda function, you have to execute my tests. And then nothing happened. I got one exception after the next with user, XPS is not available, and so on and so on. And I thought, oh my God, locally it runs perfect. What is going on here? And then I had to step into deeper in the playwright container and have to think about, okay, the things are what happened that the browser is not in the right location for an AWS lambda function because they are linked to user, but it's not available for a lambda function. So I had to create my own Docker container based on the playwright container and have to copy a lot of stuff to a location where lambda can find it. And after that it was like Magic Safari webkit is running out of the box. I thought, okay, Safari is working cool. What is with Chrome?

The next step?

Chrome is interesting because Chrome tries to save a lot of resources and make it as fast as possible. So they try to fork some processes in the background to be so fast. And then I thought, okay, lambda can't do be multi threading. Okay, so we go step back. Can I configure Chrome? Like, hey, you have to run in one process. Okay, it's possible there's a parameter next try. Okay, if I use only one process, then I have to deactivate cycle. Okay, and so on. So. So I tried a lot in the background to get the things up and running with Chrome, but at the end of all, there were three parameters and then everything worked in Chrome. And that was the. That was a really, really cool situation for us because our project are mostly running on Chrome browser and we have everything there. The only browser which is not working at the moment is Firefox because there I didn't find any parameter to deactivate this multiprocessing problem. But okay, we can live with that. And I also. So that's fine for me.

So if someone wants to try this on their own, is 7Fasta now optimized for Lambda? Like, are there any functions built in now to seven facet that makes it. So you baked in your learning there so someone doesn't have to learn this from scratch. When they try it themselves.

That's very easy at the moment because actually you can't do that because some facet doesn't implement Playwright at the moment. We implemented in the next version that we changed from Selenium over to Playwright and that's an absolute fair consideration to think about. Should we implement that stuff? So that is already up and running or available on AWS Lambda or can we handle that like that? Why not? I mean, I'm completely open. I mean with that we are very, very cool, I would say because we can now implement an event driven test automation architecture on that and we can do a lot of more stuff. Yeah, so why shouldn't we do that? Why?

Absolutely. That sounds very, very cool. So you mentioned some other technology people they're aware of REST testing and API testing I think kind of new as GraphQL endpoints maybe. So it sounds like your solution, your UI then test can interact with the REST API and talk back and forth. Does it have that type of functionality?

Yep, we implemented ktor. I don't know if you really know that. Ktor is also from Jetbrains, which brings a lot of functionality with it for interacting with REST and GraphQL out of the box. And in Kato you can choose which kind of HTTP client you really want to use. But in some vessels we use the standard Apache HTTP client under the hood from Kato and that's pretty cool because we can implement it as synchronous, asynchronous and we don't have to care about that. And that's working pretty fine for us.

What are you using Kafka for? I think I saw Kafka mention multiple times, what are you doing? What are you doing over there? What are you testing?

So a lot of applications at our company transfer messages or something like that via Kafka and we have to validate or projects have to validate. Is the message in the right format? Is the message on the right topic? How long is the time transfer from one topic for another topic and so on and so on. And if you think about we are a television company, we have a lot of stuff. We have to deliver content at the end out to the end user and there's a long chain between every small system to get the things out. And yeah, one communication part is via Kafka and so it's important for us to interact with that and also to be able to test stuff with that. So producing consuming messages, more messages, I don't know. Every team has other scenarios but it's important for us to interact with that. So we implemented it. But I'm completely open if the community says, oh no, I want to interact with an sqs, come on, feel free. Implement it, contribute to that. I mean, why not?

Love it. You know, a lot of times projects, this is open source so people can contribute and add functionality like you mentioned. I'm just wondering if this is a stumbling block that you see if someone's like, I've never used Kotlin, I don't even know, I've never heard of it. Or maybe how hard is it then to get contributors that may be more familiar with Java or JavaScript?

If you can Java, you can Kotlin. So that's easy. So before I learned Kotlin, I implemented a lot of Java and JavaScript stuff. And for Kotlin I need, I don't know, one month and then the structure was clear and it's pretty the same. But yeah, it's a small step to get up and running with Kotlin. I would say it's pretty easy.

Perfect. Now, you know we mentioned the technology piece of getting tests to run in parallel, but I assume that you had to actually design your tests the right way in order to get them to run correctly in parallel.

Of course.

Any tips on how to create tests like thinking, all right, eventually it's going to have to run in parallel, so I better not do that because it's not going to really scale really well.

Yeah, of course. So the first and the important rule is your tests have to be independent. So if that's not possible, you have a problem. That was one important rule for the design for our test, that the tests have to run in parallel and we make it like that way, our test creates his own test data in the background.

And worked only with this test data. So we can say every test is completely independent from another test and we have no collision on it. And that is one of the important rules that I can say to everybody who wants to parallelize tests. If you can't write your tests independently, you can't run it parallel or it's very, very hard. And yeah, why should you do that?

Absolutely. I think what a stumbling step is, which it sounds like you've resolved, is test data. Like you said, sometimes Test 5 needs to have a. Like if it's a patient or something like in a certain state or a document in a certain state before it could do a next step. How do you handle that?

That was pretty easy. We used the Java Faker library on that in the background and we configured that The Java Facility library brings up our data that we really wanted or that we really need. So for example, we have a registration page. So it was pretty easy to say, okay, create different kind of first names, last names and so on. So that was easy. And that brings up in the situation that we can say, okay, the test is completely independent, but there could be other scenarios where it's pretty hard. But it's always the same. You have to think about your test data that you want to use and how can you use that in an easy way with have the control over your test data and you can reuse that every time again and again. That's important because if you can't do that and you have to create the test data before by hand, then. Then I say, okay, you have a problem. You don't have to think about parallelization. You have to think about how can you handle your test data.

Right, right.

A lot of people, yeah, don't do.

That, that's for sure. That's one of the biggest failures I've seen for animation is because of the test data. Just like you mentioned, test data. Yeah, that'll be your next open source project. Hopefully.

I have to validate my test data via Excel.

Awesome. All right, Patrick, so it seems like it's fairly new. It has 25 stars. I think it should have more based on what I've heard. I actually have to try it. So I guess what's the next step? Because it sounds like you're constantly improving this and adding to it recently.

Yeah, of course. Next step is we make a great. A bigger refactoring on some facet. We want to improve stuff. We want to change to playwright because it seems more in our strategy. We want to. Yeah. Fix some failures. I mean every software has failures. And you will hear next step from Miser. What's next on AWS Lambda and how can we get an event driven architecture on that? Because if you think about AWS lambda and lambda functions and you run your test there, you see the test is running, but you don't know when the test is ready and what kind of status does the test have? So that's the next step. I already have a solution on that, but that will I post on my next blog post.

Can't wait for it. And once it is posted, hopefully I'll have a link to it in the show notes down below this podcast for sure.

Yeah, I will send you the link.

Perfect. Perfect. Okay, Patrick, before we go, is there one piece of actual advice you can give to someone to help them with their automation testing efforts and what's the best way to find or contact you or learn more about 7facetime?

Of course you should learn about synthesis. What should you learn? I'm a fan of learning programming. It's important to learn programming stuff. It's not enough to say, okay, I can implement Java stuff. You have to learn programming. You have to learn programming on Java. You have to learn programming on JavaScript to get the feedback, the feeling, okay, how can you solve this stuff if you have that next step is go to Test Automation University. You learn a lot of stuff there. It's great, it's great content there, great teachers, makes a lot of fun and you should use that. There's a lot of information there and that brings everybody up on testing and test automation. And the last thing I would say what is really important is don't stand still. Move every time forward, think about what could be the next interesting step. I mean there are a lot of interesting topics like aws Lambda or AI or I don't know. Yeah. So please don't stand still. And I would love it. We have a lot of open source projects because open source is very, very cool. It gives back to the community what's going on, what's happening. And yeah, I would say that's really important for us.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to test guild.com a375 and while you're there, make sure to click on the Try for Free Today link under the exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. 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.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.