Gatling Studio: Start Performance Testing in Minutes (No Expertise Required) with Shaun Brown and Stephane Landelle

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 test is on a major testing podcast.

Hey. Today we're tackling what I think is one of the biggest frustrations for testers and SDATs in our community. Teams want performance testing, but most don't have the time, the skills or the tooling to actually get it off the ground. That sounds familiar. You're in the right place because Gatling just changed the entire onboarding experience again. In this episode, we're diving into how you can go from we should do performance testing to actually building, debugging and scaling load test in minutes, not weeks. And to show you how this all works, I've got Stefan Lindell, the creator of Gatling himself, along with Sean Brown. They're here to walk us through what's new, including an exclusive behind the scenes look at Gatling Studio. The tool aimed to make performance testing accessible to every team, regardless of skill level. So whether you're completely new to load testing or you've been burned by complex performance tools in the past, this conversation will show you a simpler path forward. You don't want to miss it. Check it out. Let's jump in. This episode is brought to you by Gatling Studio because performance testing shouldn't require a PhD in performance engineering. If you've ever wanted to start load testing but felt blocked by setup, scripting or too complexity, Gatling Studio lets you record, debug and generate tests in minutes so your team could ship faster, catch issues earlier, and finally make performance part of everyday development. Try for yourself for free@gatlinkio by using that special link down below. Hey guys, welcome to the Guild.

Hey. Hi Joe. Great to be here today and great to be talking about what we've cooked for the last few years since last time we talked about at Test Guild. So yeah, if I remember, yeah, we did a kind of online conference a few years ago, was a great time.

Few years. It's still almost 10 years ago, I think.

Almost 10 years already. Oh man, I'm getting old. Yeah. So since last time, yeah, lots of things have changed on the Gatting side. So you know that we're a company, so we provide both a community edition that's open Source, published on Apache 2 license, and also an enterprise version. The company has been growing steadily. It's honestly a great journey serving absolutely awesome customers. So we're still on the Same mission, we're only focused on load testing. And since day one, I would say that our mission was trying to make load test crafting and automation easier and kind for everyone. So not only performance engineers or QA specialists, but also developers. I originally created this tool for me and my idea was that crafting and automating the load test should be easier so that tech experts and performance engineers would be really focused on building a load test strategy and investigating and fixing the performance issues, not building the tests themselves, not maintaining them, because, well, that's not where their core value is, in my opinion. While developers who represent them, I would say the vast majority of the IT departments are more familiar with the code, more familiar with the APIs, so they would be probably more predictive regarding desk crafting itself.

Absolutely. And Stefan, that's a good point. Back in the day, you won the first tooling I saw for performance testing that was almost more developer native than all the other tools used to be. Like after everything was done, you go to the specialized team that had to do performance testing. So you really opened up the doors, I think, to other companies doing similar approaches. Now what gave you this vision of, you know, like you said, you said developers obviously are the best people probably to have it already in their IDE and ready to go. Why did you focus on this though?

Yeah, it was really because of silos in large organizations where I was working on back then, like banks, where it was complicated to break those silos back then. It was before the DevOps era where we tried to break those silos and I needed to move faster back then. Also we didn't have the all the provisioning solutions that we have now, so I wanted to be able to build a test earlier in the lifecycle development. I didn't want to have to wait for a pre production environment to be available. I wanted to be able to run some performance tests on pure environment, even if it's not of the same scale and not the similar architecture and production. I was able to figure out some performance issues early, before they shipped in production and hurt end users and customers.

Great.

Another cool development I've noticed. I could have sworn maybe I'm wrong. You started using Scala, I think. But I've noticed over the years you keep adding support, so maybe a little bit more about the languages because that may have been a stumbling block for people. So maybe a little bit more of what you support now.

Yeah, exactly. So indeed. When I first created Gatling, so it was a tool for me and back then Scala was pretty high and we were the general feeling that it was everywhere in every tech conference and we got the feeling that it could replace Java. And honestly it's a great programming language and that's still how the core of Gatling is implemented. That's also the programming language we use for the backend in Gatling Enterprise. It's an awesome ecosystem and programming language, but it's not for the fainted heart. I would say it's more of an expert language than your go to solution with let's say regular developers or QA people where you just want to build things without all the advanced concepts and all the nice way to program with a functional programming. So I think it's now five years ago almost we introduced an SDK for Java that you can also use from Kotlin. Almost two years ago we also introduced an SDK for JavaScript that you can also use with TypeScript. And those other SDKs are growing steadily. I think that Java and Kotlin combined now represents the same volume of usage as a Scala despite the huge historical test use that were written in Scala before those other languages were introduced. And we see more and more organizations that used to use the Scala SDK now moving away and migrating to Java because it's easier to onboard people. I would say that the it's easier to onboard people not because it's more complicated in Scala to write Gatling tests. So as I said, Scala is a very powerful yet language, yet it has more complicated concepts. But in the end you just use the Gatling SDK and whatever the language, the different Gatling SDKs are very similar. We wanted to bring the same, very similar user experience so it was easier to learn one SDK or another. It was easy to have people using the different SDKs communicate with each other and compare what they've done. It's more about, I would say Scala having kind of bad reputation of complexity and shying people away. One advantage that I can see with the Java SDK is that it compiles faster, compiles your test faster. So yeah, bit of a better user experience on this side I would say excellent.

Also, you know, a lot of our listeners are, you know, software developers in tests, QA or automation engineers. Just curious to get your view on do you still see testing as code as an important foundation for performance testing today or do you see it more going towards like AI generated code and we don't have to worry about it anymore.

So I still strongly believe in test as code, but AI is very good at generating code, but you still need to check what it actually does. But I see AI as a very good helper with crafting the code and generating the code. Like lately I've seen a user generating Gatling code with Cursor and the result was pretty nice. But I told him why are you generating Scala code? And he said, oh, I just didn't know. Kersol just generated this for me. But he asked Cursor to transform the Scala code in Java in just one command. It migrated all this code. So I see AI as a very good assistant for crafting code. And this is a field that we want to explore. We want to provide typically a better documentation. So that's AI can analyze our documentations way better and it can help you build Gatling code way faster.

Love it. And as I mentioned earlier, you were one of the first performance tools I thought that really started to embrace the developer experience or the developer's workflow. Is that still a main focus of what you're focusing on now or do you see with AI coming in that it's kind of going to shift? Like I said, you've been. I don't know what's happening, but it seems like you must have found a pain point because you're growing and you're releasing more and more in things. So which of you know on the experience of the tooling or is it still developer first type of experience that you're looking for?

We tried different experiences before AI started becoming a huge thing. We started experimenting with no code approaches. So really pure no code with a graphical user interface with blocks so that you can craft your tests. We released an MVP for that that's available in Gatling Enterprise. Well, it's being used, but I think both it would require from us a huge effort to make it feature complete compared to the code SDK. And in lots of cases there are some places when you need to manage some auth tokens, for example, these kind of things. At some point you need some code and you can see that lots of no code solution lets you actually embed some pieces of code all over the place. So this experiment was. Well, it's a nice tool if you just need to load test a few URLs just to get started. Typically it can help you with that. So we've started introducing a new product named Gatling Studio. What we wanted to do with that was both help Gatling test task code users and non test task code users. What I mean by that is that for the current Gatling test as code. So first you need to get started. So either if you're very familiar with the code, if you're very familiar with the API and you're familiar with coding, you can jump directly into the code. But if you're not familiar with the API. So for example, if you start, if you want to load test a black box application, something that was not developed in your company but a product that you purchased, for example, how can you get started? So we already have a component named a recorder that helps you bootstrap a test by recording from your browser.

So it works typically as a proxy and it's very cumbersome to configure on your HTTP browsers. Nowadays you need to be familiar with root certificates how to configure them because it's a manual in the middle so can inspect your secure traffic RTPS traffic. So it's kind of complicated to configure. You need to be familiar with the DE encryption concepts behind so that you can install a root certificate in your browser. You would have to do the same things for other proxy tools like Charles Proxy for example, but lots of people are not very familiar with these concepts so it's not super convenient. So we wanted to provide a better recording and replay experience for these users. And our first try was trying to build a browser extension so that the idea was that all components would directly live inside the browser where it could see the DOM and other requests directly in the browser so you don't have to install a root certificate. The problem with this approach was that the browsers, editors, browser vendors, well kind of blot features, these kind of features for new extensions and they were progressively sunsetting them for existing extensions. So this solution was not properly working. So it took time to us to drop on this IDE and change to a different implementation based on Electron. So the idea is still to gear to automate a browser to capture the traffic in HR format so that you can record directly from your browser. It provides you a way better experience than the existing recorder. There will still be a use case for proxy based solutions when your client is not a web browser like a local application or desktop application where you would still have to configure a proxy. So this is still covered by the existing recorder, but probably something that will migrate to the new Gatling Studio. And then the other thing was there are lots of manual things that you want to repeat once you have the raw recording from your browser. You want to filter lots of domains and URLs that you're not interested in like typically static resources and all the trackers that your application or website might ship. Then you probably you want to analyze or probably have the tool analyzed for you correlation so checks in Gatling, try to test them directly without running the test, but test directly your regular expressions or JSON path, these kind of things trying to see what you can capture with different expressions in the responses and at some point have the tool also directly infer them for you and do most of the work for you. You want also to have a better debugging experience with Gatling. So for now it's more run into run and check the logs and see what went wrong with the studio. We want to display the debug results in a better fashion, more visual way so you can identify each isolated payload with syntactic coloration and see the difference between what you recorded and what you experience with your local run so that you can see what went wrong. So overall this is a tool that will both help people who are not familiar with Gatling on board with Gatling and have a better crafting and debugging experience and also possibly ship some AI features that basically it would be one of the things AI is very good at is searching documentation and building a better search engine for documentation. So help you with cracking the test. So this would serve both existing Gatling users having a better crafting experience and also better onboarding tool, better onboarding experience for new users.

Nice. I think when people hear no code, low code, it's a myth that they think it's not as powerful or it's only for beginners. But I actually know a lot of developers that actually prefer this type of approach because a lot of people don't even know where to get started with load testing. So this actually walked them through as well. Like the whole process of load testing, it's not just okay, here's a load testing tool, go at it. Does it give you any sort of guidance or any sort of like visual how to get started? Walk them through the process.

So this is the kind of things that we'll introduce later. So the first iteration that we're releasing is mvp. So we definitely want feedback from it to see if it gets some traction, if it's. If we're heading the right direction, in the right direction. So really download it, give it a try and give us some feedback. But the walkthrough is more guided. Like yeah, record, filter out whatever you request or domain you're not interested and then generate the code. Then yeah, it will be more guided like also we'd introduce steps to define the injection profile. So how many virtual users do you want to start and what kind of shape of load you want to generate? Yeah, so I have a more walkthrough, a better walkthrough experience.

Love it. So I'm dying to see it. I'm sure people want to see it as well. Maybe that. Sean, you can show it and then we can have a more discussion around it once people see what we're talking about here.

Okay, awesome. Thanks, Joe. Let's take a quick look at how easy it is to get started with Gatling Studio. I'm on the Gatling homepage and for you to get your copy of Gatling Studio, you can go to Product and then under latest releases, Gatling Studio and from the Gatling Studio page you can click the Download button and then here you have a choice between selecting Windows, Mac or Linux installers. There's feature parity between all three versions, so choose whichever one best suits your wish.

Workspace.

I already have Gatling and Studio installed on my computer, so I'll move over there so we can take a closer look at the product itself. Okay, here we are on the landing screen. Once you've downloaded and signed into Gatling Studio, you do need a Gatling Enterprise Edition account, but those are free to sign up for and the login process is quite straightforward. So from here let's do a quick overview of the features inside Gatling Studio and then we'll create a real recording and a load test script from that recording. On the left menu there are three main subpages and then a settings page. Let's start with an overview of the menu options. The first menu option, Workspace, is a way for you to organize your work. You can create one or more workspaces and they may be usable for things like organizing your work by project or organizing your work by team. The second option is Recordings. This is what we'll come back to to start our own recording here in just a minute. From here you can record a new journey which launches a web browser dedicated to recording your actions. Or you can import an existing recording if it's in the format of a HAR file. Third is the Scenarios page. Scenarios are the virtual user actions that will be included in your load test and that are generated from the recording. We'll get back to that again in our demo just in a second. Finally, there's a Settings page. In the Settings page, you can set the browser that you want to use to make recordings. Right now, Gatling Studio only supports Chromium based browsers. We will automatically detect a browser. Or you can use manual configuration to point the application to the browser you wish to use. Okay, let's start by making a recording. So I'll go back to the recordings page and I will click create a new recording. Here it comes preloaded with Gatling's own load testing demo page, Ecom Gatling IO. So we'll click start a recording and this will open a Chrome window. And now as the page loads, we can take a quick look and see that it is an E commerce site, at least a mocked one, where you can add items to a cart, search for products.

Log in and go to your shopping cart and check out. So let's try to behave like a real shopper might. We can add something to our cart, like this black earthen bottle. And maybe we want to buy a T shirt, but we want to see the different colors that are available. So let's search for T shirt. Okay, so we have multiple T shirt color options. Today I would like to buy the yellow T shirt. So I'll add that to my cart. And maybe I want to know more about the pink T shirt. So we could open the page for the pink T shirt, look at it, but then decide it's not for us and go back to the main page. I will log in. The app comes preloaded with credentials. Finally, let's go to the cart and check out. Okay, check out. All right. So now we've completed the buyer journey and we can simply close the window and you can see that Gatling Studio automatically ends the recording. So this lets you have a concise and accurate depiction of the user actions. We can save this. Let's call it Gatling Buyer journey and click save. Now we are looking at our recording here and you can see that we've captured each one of the requests. So at the beginning you can see there's a series of get requests and then the type HTML, css, JavaScript image files, any one of these, if you click on it, you, you will get the request details and the response details can close that. So from this what we want to do is create a load test. So what we will do is click the scenario button and that will bring up the scenario filtering modal. Here we have two primary filters. The first one is to filter on domains. In the case of our demo app, this is pretty straightforward because there's just the main front facing web domain and then the API In a more complex, you may see dozens of domains here that are calling external services. For example, next static resources filter. So it is automatically set to Exclude the static resources, which is traditional in load testing. But if we toggle it, we can see that we can add those static resources back in if you have a reason to do so. So let's leave the static resources out and we'll leave both of the domains in in this case and then we will click the filter recording button. All right, so now we have successfully created a scenario. The scenario consists of a series of requests and pauses. The requests are the ones that we captured and the pauses are the actual pauses between steps that were experienced by the users. Request to the homepage, a 10 second pause request to the API pause request to the session endpoint pause, etc. How do we convert this scenario into a Gatling load test? We click the Export Project button and choose a base URL. In this case we want to use the API URL because it's the most frequently called URL and export. And I will put this on my desktop and click Save. Okay, so you can see I've done this more than once. I have this Java maven zip file up here at the top. If I open this and expand it, I will have folder. The folder contains a readme file src folder and some additional files. A POM XML as a configuration file and the Maven wrapper. Let's go to our IDE.

And open that file. We'll open the folder and have a look and see what's included inside. When you open the folder, it will open to the readme file. The readme file gives you very detailed, easy to follow instructions to take the test that you've just created and then run it on Gatling Enterprise Edition. I won't go through those steps in this demo. Let's take a quick look at the project structure so you can understand where to go from here. Inside the SRC folder, there's the Test and Java folder. This contains your simulations so we can open this file. And this is the simulation that was generated from the scenario in Gatling Studio. So this is a complete load test which you could run locally or again run on Gatling's Enterprise Edition. I'm going to just scroll down and point out two features in here that you should be aware of. The first one is here where the line starts with Scenario Builder. This is the beginning of your user journey. This includes now all the way through here, each of the calls to the respective endpoints with the pauses added in between. And then the second thing I want to point out is at the bottom where we have this setup block. The setup block describes how Virtual users will be added to your simulation. In the case of when you first create the export, we just add one user to the setup block so that it's really straightforward. You can run it and just validate that the script does in fact work work. But this is where you can customize how users arrive at your application to mirror what you actually see in your production application or what you're trying to prove with your load test. So let's flip back to Gatling Studio for one second, go back to the homepage and do a quick summary. So with Gatling Studio, what you can do is capture real user behaviors in your web browser as a recording or import an existing HAR file as a recording. From that you can create a scenario where you can filter out unnecessary items like static resources or calls to domains that are irrelevant for you. Then you can export that as a fully functional Java maven project, which you can either run in your IDE or upload to Gatling Enterprise Edition and run with distributed testing.

That's it.

And I hope this was informative. And download Gatling Studio today.

Nice. How does it handle correlation? Like if you have IDs in the background being passed? I know back in the day with Loadrunner I had to record like five times and then do a diff and see what was dynamic.

So it doesn't yet. That's one of the features that we'll implement in the next versions. Maybe that's something that will be AI based. The concern possibly is with privacy. You know that lots of organizations are privacy pretty concerned about sending all your data and in particular all your sensitive data like credentials, these kind of things to an AI. That's how some major security breaches happened in the past days, if I remember correctly. Yeah, there was a major breach because some users uploaded an harm in their support solution and then this platform got hacked and then they were able to get access to some tokens. I think there's lots of things that we can do on this side without AI. It's basically trying to isolate the request parameters and then try to figure out some string occurrences elsewhere. So I think that we can implement these features without relying to AI. At least we'll try to because of privacy concerns. We don't want to be the next platform that will cause a huge security breach in major organizations because we uploaded your traffic in the background to our platform without your actual knowledge. Yeah, we don't want this kind of issues and to cause these kind of issues. So this one, this is one of the next stories that we want to implement.

All right, so for the demo it looked really smooth. But from your perspective, how does Studio change the ad boarding experience for a team starting with Gatling? Is this what you point them to first or do you just gauge the skills of the team?

So this is where we're going to point users first. Definitely.

We're going to sunset the existing recorder and this will be the go to solution when you want to get started. So in one sense, the IDE is the web UI for Gatling and it's a bit complicated to implement plugins for all the different IDs that you might be using. Some people might be using IntelliJ IDE, some might be using VS Code, some even might be using Eclipse. So for now with the Studio, we decided to go with a standalone tool instead of an IDE plugin. This might evolve in the future, but we needed a tool to complement the existing IDE experience, typically for the recording, typically for figuring out correlations checks. So this is not something that's implemented yet. This is something that is going to come in the next release, again looking for feedback. This will be the go to solution when you want to go and test and craft Gatling tests. So it will still be exporting Gatling code in Maven Gradle, NPM projects, et cetera. So you can check what happens in the underneath. You'll also be able to ultimately run also directly the code and compare to the recording. So you can see the impact of your different changes and also set different, set new references like, okay, this is my test and now it works. This is the result that I'm experiencing. So you can capture, you will be able to capture an HR from this, so you can set it as a reference. So if you keep on editing or rerunning your application and the application has changed in between, you'll be able to figure out the changes and figure out why your test now breaks possibly at some point. Also, for example, use AI or another solution to try to automatically fix the test. Like some IDS change in the payload and you need to look for it in a different place. These kind of things.

I know when I was in performance testing like almost 30 years ago, unfortunately it was kind of easy to write the test. The hard part was like looking at all the results, the logs, the counters and know, okay, yeah, response time's high, but why? I don't know, like you had to dig and say, oh, it's the mainframe that's spinning or something. Does this give you any insight into that? Maybe does AI help with that to say, yes, it's high and it's high. Because of this.

There are two different things. So on Gatling Enterprise we also soon release a feature that provides you with a AI generated reports. So currently with Gatling Enterprise you have a dashboard with lots of different metrics. We have a summary that gives you some basic insights on what went wrong. But what do you want to improve this experience? Like this is the kind of metrics that you should be looking at because it looks wrong so you don't immediately have to. Well, the tool will help you figure out which exact metrics to go and look at to figure out why your test went wrong. So for example, where you're running with saturated cpu, so you weren't able to generate the load that you were expecting because you don't have enough load generators or your load generators are too small, not enough cpu, if you have some network issues, if you have some too many errors, too many connection problems, TCP or tls, this kind of thing. So you will be able to have a nice summary of your test that will directly point you to the different metrics that went wrong to help you analyze what your test test was doing wrong. Then when you need to figure out why one spec. So this summary will help you figure out assuming that your test was correct and performed properly and the load generators were fine, that the load balancers were fine, these kind of things, and that the traffic actually went to your code and your application. We all tell you, oh, these requests ran wrong. In particular, those ones have poor response times, those ones have higher ratios. But then if you want to analyze them, we complement observability tools. We won't compete with huge vendors like Datadog, like Dynatrace and all the other ones in the observability space who are putting lots of efforts into providing tools to analyze the root cause of the performance issues. We have the client side metrics, they have the server side metrics. And there are also some cases where the observability stack is blind that lets you observe your infrastructure. But they cannot help you investigate the network between the load generators, the clients and your edge endpoints. And also they don't monitor what your edge endpoints are doing. So for example, every time your load balancers are saturated, both in terms of TCP and TLS end shakes, you won't see that in the observability tool. So this is also the kind of things that we'll be able to highlight. Awesome.

So I'm not sure how long this has been out For. But have you got any feedback yet from it? And so, you know, for early users, anything that surprised you, like, oh, no, we designed it for this, but we're noticing a pattern where people are using it for that, anything like that?

I would say that the main difficulty, kind of, as usual, it's kind of usual business for us, but every time it's a bit complicated, it's deploying components in enterprise networks where the network is isolated from the Internet with a man in the middle proxy where you need to install some root certificates. We tackle those issues on Gatling Enterprise because Gatling Enterprise is in a hybrid mode where you can bring your own generators and still have the rest of the infrastructure. All the stats handling and database is on our side. So we had to tackle all those connectivity issues between the customer network, the corporate network and our cloud. And we have the same kind of issues to tackle with the Studio because it also communicates with our SaaS solution. So yeah, it was a bit similar. And so we're currently working on improving the experience in corporate networks. So it's awesome that this is a typical example where Community helps. Like we have a user, I think he's from Poland and he's helping us debugging this issue in his CorePoint network. He's been very, very helpful and very reactive and that's really a good demonstration of the power of Community. Yeah. Because we cannot build ourselves all the different corporate setups that you can find in the wild. So we can try to imagine things on our side in the labs, but sometimes you need to kind of debug on the user's machine. And yeah, this Community member has been very helpful.

Love it. So talking about Community, once again, you said in the beginning, Gatling, you have an open source version, you have Gatling Enterprise. I forgot if you mentioned maybe I missed it. Where does Studio fit in? Is there an open source version? And then do you have enterprise versions you can unlock? Eventually. How does that work?

So for now it's not open source, but it's completely free. Just one thing is that it requires you to create an account on our cloud platform, but then you can use it with a free tier. It doesn't consume any credits and for now the plan is to keep things like this.

So what's the best place for people to start? They heard about it, they saw it, they want to try it. Where do they get their hands on the Studio?

Yeah, so as Sean showed, you can just download it on our website and install it. It's properly signed, so it should be accepted on any different platforms, both Mac and Windows, and then you can get started. If you don't have a Gattling Enterprise account yet, it will prompt you to create one and connect to it and that's it.

Cool.

All right, before we go, any piece of advice you can give to testers or automation engineers who want to get into performance testing but aren't sure where to begin.

First, don't get scared. It's not that complicated and you need to get started somewhere. So don't try to build a cathedral from one go. Start small and then build on top of it. Even just load testing your homepage is the first very good baby step. At least you get something. You get to test a piece of your infrastructure, a piece of your application and you might even just with that you might be able to find some things and we see that a lot like typically the load balancers not being properly sized, these kind of things. So yeah, get started. And yeah, it's not that complicated and.

I highly recommend you check it out now Gatling Studio for yourself using that link down below and see how easy it is for you and your team to get started now with performance testing. Check it out. Thanks again for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com a570 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 and 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 every 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@test guild.com where you become part of our elite circle driving innovation and 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 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.