ScalaTest for API Testing of MicroServices with Zubair Haque

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 you're in for a treat because you're going to get a little bit of automation and a little bit of performance. And I'm really excited about this episode because today we'll be talking with Zubair all about Scala tests for functional and performance testing. Zubair is a detailed oriented software engineer and test. He has extensive knowledge and experience with over 10 years of experience in the product development domain. He has expertise in a bunch of topics like Selenium architecture for test automation, solution architecture for test automation, authoring, test strategies, test tooling and more. Especially on how to really integrate all this in a fast paced CICD environment. So a bunch of real world information coming your way. If you have anything to do with Java, you don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites with work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Lazy Bear welcome to the Guild.

Hi Joe, how's it going? I'm so happy to be here and thanks for having me.

Thank you so much for joining us today. Really excited about this topic. As I mentioned in the intro, but before we get into it, is anything I missed in your bio that you want the Guild to know more about?

No, I'll just piggyback off of what you said. I'm Zubair. I'm currently working at the Climate Corporation, which is a leader in the agriculture technology industry. I've been there for about two years now. I have about a decade of experience, a little more than that. And more than half of that time I've spent being an sdet with the core focus on automated testing of client server systems in a Linux environment and a Windows environment.

Also, what's interesting, before we get into it, I know you touch a lot of things. You do automation, you do integration testing and do performance testing. What exactly is your role? Because a lot of times sometimes people get pigeonholed into doing one thing. It sounds like you're doing a bunch of different things, right?

So in my current role at Climate, I'm a lead estet which entails being in charge of all quality assurance processes and activities for our product platform. We're a big data IoT shop that deals with cloud computing in a microservices architecture. Our goal basically is to help farmers manage their farm operations. We're also one of the market share leaders in the digital ag tech space. So I will do a lot of things such as manually testing APIs through Postman, writing integration tests and Scala tests for microservices, doing performance testing and looking into production issues.

Very cool. So I'm going to start really high level and I thought we'd dive into it step by step. So first, Scala. I've heard of Scala, I know Gatling uses it, but I actually have not done much with it. So I'm not sure how familiar folks are with Scala. So at a really high level, what is Scala?

So Scala is a functional programming language that's on the JVM and it's gained popularity for two reasons. One is for the stateless programming and the second is for the lazy evaluation. So as you've heard, there's a lot of AWS lambda. So when you call the function it does a lazy evaluation and then it gives you the output.

Would you choose this language over java then, or JavaScript like is it a programming language or is it a language you use to test other languages? I don't know if that makes any sense.

That makes a lot of sense, right? So having a diversified background, I've worked with all kinds of tech stacks all the way from NET to Ruby on Rails to Java Spring and now even Java Spring boot. My interpretation, or my best practice that I would give to people is to write the API tests in the same language that the backend APIs are written. So if you're going to write integration tests and your backend services in Scala, you should write those tests in Scala. If your backend services and Golang, you should use go test. If your backend services flask. In Python you should use pytest. So that's my reasoning of using Scala, right? And the reason for that is right. In this microservices architecture of contract driven testing that we're in right now, what basically happens is there's several changes being made continuously in a CI environment. And let's just say a dev makes a change and he breaks about 10 tests. If the tests are written in the same backend language and it lives in the same repository, it's easy for them to diagnose those failures, right? Pre merge or even post merge, what.

Do you think is the reason For Scala being so popular nowadays, I didn't actually know it was that popular on the back end. So do you see as a trend as more developers embracing Scala on the back end?

Yes. Scala, I would say is just like any general purpose programming language. It also lives on the jvm, such as Haskell, Lisp, Clojure. These are more concise languages and they're less verbose than Java is. But as you can see, there's been a paradigm shift in the software engineering industry where even JavaScript is becoming more functional and so is Python and other languages. So that's why I would say Scala is gaining a lot of popularity, especially in the big data space.

So you did mention about you do a lot of testing of microservices. So what gave you the idea then to choose Scalar as the language you would use for integration testing?

So during my job interview we talked a lot about API automation and testing best practices. I was originally hired to write the test using the pytest framework, using the request library to validate all HTTP requests. My first day on the job when I showed up, we were making enhancements to several APIs. Right? Most of them were written in Clojure and Scala, and I was outnumbered by the rest of the team to basically write the test in Scala. But it was great because I'm also using Rest Assured, the Java JAR file, which is one of the top 20 software testing tools on your website that I recently read about.

Cool. So I would think pytest was easier. So in your experience, how hard was it since you were expecting to use PI tests and you end up using Scala, how hard was it to make the transition then from PI test to Scala to write your test?

So I just read the Scala test documentation and I started to look for familiarities with things that resonate with me. So I'm a huge proponent of the BDD testing style of Given when then. So I decided to use the Java JAR file for Rest Assured, which is one of the top 20 testing tools in your website recently that I read about. And I also chose the Scala test style of Fun Spec, which derives from my familiarity with RSpec and RSpec is a very popular BDD testing framework and the suite is styled in a way where there's a regular test class, right? And there's a describe statement which basically tests the API, followed by a nested it statements which test the variance, various scenarios.

Nice. So I know a Rest Assured, it has almost like a BDD type syntax. So when you're saying you're using BDD testing, is that. Is that what you're using? Rest Assured, using the BDD type syntax given when, then and then using Fun Spec as well to drive it.

Yes, that's correct. So since Scala is on the jvm, we have access to all the JAR files that we need from Java World and we also have Scala libraries that we can pull in and add to our Build sbt. The Build SBT is basically just like your maven file. It's also the same as Requirements Test or your gem file in Ruby. When I say refer to Build sbt in this podcast, we're going to be referring to the requirements txt, the gem file, the maven file, a place where you can add your dependencies and your dependency versions. I'm using JSON4S, which is the native serialization library, which is, which is also used in Java, and Rest Assured, which is a DSL used for writing and maintaining tests for restful APIs.

So because your developers are using Scala as well, where does your test live? Does it actually live in the same project as the development environment or the development branch?

Yes, that's correct, you're right. So since the tests live in the same repository, I have added an IT directory which is an integration directory which basically tests all the CRUD calls, the contract of the API which we get from Open Spec API. And I test the various scenarios that I can that I see from the swagger documentation that we're getting now. I also have an end to end test suite that lives in a separate repository which is also written in Scala. This one tests our entire digital farming platform from end to end, which interacts with more than six microservices at a time. So we have one suite that lives in the repository that just tests the service and the CRUD calls itself. And then we have one that that lives outside the repository that runs from end to end.

So why are you a fan of bdd? Is it because you want to also have the developers help you contribute to it? Since you're using the same language, Are they also contributing to the bdd? Or you just find it's easier to create these type of tests using bdd?

The BDD styling is a preference that I've had for a while. There's also Scala JHTTP which is an alternative to Rest Assured. But I like Rest Assured. There's a lot of documentation behind it. It's a preferred tool for behavior driven development testing.

Nice. So once again, this might sound like a dumb question. So Scala is a programming language. What Is Scala test is that like equivalent to Java with Junit?

Yes, that's correct. So Junit is the built in testing framework for Java unit. Test is the built in testing framework for Python. And scalatest is the built in testing framework for Scala. You can add the library dependencies just the same way you would to maven in your build SBT file.

Nice. So once again it sounds like. Because even though it's Java, if you're using a Java application or a Java development environment, it sounds like you could also use Scala. It's either or, right? Does Scala work with all types of Java type of development projects?

Yeah, if you have a Java Spring boot application like that's very popular right now and we've written a few services in Java Spring boot. If you want, you can add Scala test to your maven palm XML and you can use Scala test inside of a Java project as well. You can also do that in a popular Lisp language closure. You can also use scalatest if you add that into your project clj, right? So you can use scalatest in any JVM project or you can write the test in your own separate repository, meaning that they don't live in your base directory of your project, they live in a separate project and you can use scalatest there too.

So I know with Selenium they have like a Hamcress matchers type library you can use that makes it doing verification points easier. Does scalatest have anything similar to that?

Scalatest has a mattress trait which is all the built in assertions. When you import scalatest, you have to extend that with your base class, such as class test skill extends matchers. Once you extend the trait matchers, you get all of the built in assertions that come with it. For those that don't know what a trait is in Scala, a Scala trait can be used to share interfaces between things and classes. This is a similar situation for those who have used Junit and rest assured, where you have a base class that extends from your test class to Scala, you would just have a base trait basically that does that. Most of these matchers use the keyword should. And let me give you an example of that. When you make an HTTP request, you're validating some JSON and your JSON response will have a bunch of key value pairs, right? You will be able to make assertions such as key should equal. So let's just say there's an ID key and the value for that is 65. So it would be ID should equal 65 or the ID should be 65. So that's how easy it is to use matchers. When you make an HTTP request, you're validating some JSON, possibly some key value pairs, right? So you will make assertions such as key should equal a value. So let's just say your key is an id, right? And that should return a string. So you would say something like the ID should equal 65 or your ID should be 65. So that's the best way to use the Scala test masters. A more useful example would be when working in a big data IoT environment like we are, you can loop over an entire Java collection using the for each method, right? Which is built into Scala, which is so powerful. Right? Because essentially you're saying for each of these keys that are in this array, they should all equal an expected value. For validating big data sets and nested JSON, scalatest has been very useful. Now an alternative is Junit JSON paths. You can get JSON paths, but those are very fragile because you're getting a list, you're getting an integer. If the JSON schema was to change in any way, let's just say you're updating versions of an API from version one to version two. Once you update and the schema changes from an object of arrays to a list of just integers in it, it would basically break your tests. A more useful example would also be when working in a big data environment, you can loop over a collection using the for each built in Scala method, which is also powerful because you're essentially saying for each of these keys that are inside of this JSON object, they should equal an expected value. For validating big data sets and nested JSON, scalatest has been very useful as opposed to using Junit's get JSON path, when you use Junit's getjson path, what basically happens is if the schema changes at any time, which it probably will, between a version one to a version two upgrade of an API, it'll break your test, making them more fragile.

So it sounds like it has matches that people are familiar with. I know another common functionality people are looking for is tagging of test. Do you have any recommendations on how to use tagging? Or does Scala Test have any sort of tagging feature you use all the time when you do your test?

Yeah. So scalatest has a couple of things we could do that is very useful, but one of your previous guests, Swasti Sharma, had came onto your podcast and touched on the subject of feature flags. Right. We have a similar fast Paced CICD agile environment. There's always a scarcity of time when it comes to testing and validation, so scalatest will allow you to define test categories and filter your tests based on their tags. From my cucumber rspec days, what I do remember is creating rake tasks to basically run them on command when changes are made. The test runner in Scala has a vast amount of command line arguments you can utilize to choose from to basically include some test scenarios during runtime or even exclude them as you wish. Scala's build tool allows you to use the AddCommand Alias function to create custom tasks to run in your shell. You can add the AddCommand Alias function to your build SBT file. The function will take two arguments, name and value name. We can basically pass in any test tag as a string. We'll call it smoketest. So we'll pass in smoke test in quotes because that'll make it a string. And the value argument we can pass in the test only hyphen, hyphen, dash n command line argument and our tag name. So let me explain what this is doing. The test only task filters out the specific test cases you want to run. The dash n command line argument indicates that to the test runner to include these tests that are tagged. So now when you go to the command line, you can just run SBT smoke test and it will run your tag tests for you.

It sounds similar to Maven. I used to tag my test as say sanity and I do a Maven dash D tag name equals sanity and we just run that subset of tests within all my tests. It sounds like this is similar.

Yep, it's basically the same thing, but just in scaletop.

Nice. So do you have any recommendations on tagging so that it doesn't get out of control? Because one thing I noticed where sometimes people start creating a bunch of different tags and they totally forget about what each tag or what test is doing.

That does get very out of hand, you know, as your system grows. Right. It will definitely get out of hand. But one of the best practices I had when I worked in a big data healthcare environment was I tagged those tests by module. So let's just say there is a change to a specific module like prescriptions. You would run something like SBT Prescriptions, Right? And that would run all of your prescription tests because you're doing a targeted regression test based on the prescription module, which encompasses several APIs. If you run those prescription tests only you can make sure at a high level nothing is broken in that module. You can do that. Now you can also do things like smoke test and regression, but things like having a regression tag, basically it's going to maybe encompass running your entire suite, because a regression test is basically a safety net you're throwing out there to make sure nothing is broken with every incremental change you've made. So regression tag seems a little bit like overdoing it, but tagging a test based on a module, I think that's better targeted regression in my humble opinion.

So in your particular flow, it sounds like you're just testing microservices. What's your percentage of like say, API test versus UI test? Do you ever do any type of UI test? And if so, is that completely separate from the Scala test framework you have set up?

So yeah, basically we have a test pyramid where we have the majority of our tests are unit tests which is written inside of the repo. Then the second majority is for the API integration tests, which are the contract driven API tests that also test your end to end workflow as well as your CRUD calls and our cucumber page object model front end tests, those are for the web based applications and those tests are fewer than the integration test, because the integration test, the API test, they don't take as much time to run those.

Right, perfect. So I want to switch gears to performance testing. But before I do it, are there any tips you've learned along the way for making your microservice test even better or what not to do things like that?

So I would definitely go along with saying that people should definitely have a base class. Now if you're working with Scala, I would definitely advise you to have a base trait that would be a good way to tag your test. I would also encourage people to make helper functions. Like for authentication, we have a helper function that I've created for authentication, which basically logs into the app through the back end, makes a post request, grabs your token and stores it and makes it a part of your query parameter. Then I would also create helper functions for post requests, put requests, get requests and delete requests. The reason I do that is it provides better readability for your test and it makes for more of a dry sweep so you're not repeating yourself all over the place.

Awesome. So like I said, I want to switch gears to performance testing. So performance testing I think a lot of people overlook, but it sounds like this might be approach, it might not be approaches. You have a bunch of functional API tests now written in Scala, but I'm thinking because Gatling also uses Scala, you can reuse those functional tests and then make them performance tests. Am I thinking that correctly?

Yes, you're thinking that correctly. Now, we are using the free version of Gatling, not the one that has a ui. So I'm scripting my performance test just the way I'm scripting my API test. You're correct about that. And these performance tests, right, they're a key source of information for all of the developers, stakeholders, anyone that's involved. And in a microservices environment, we basically have blue green deployments where we deploy a service for a short amount of time and we check the health of that service. And if that service is functioning correctly with all of the other services in our platform, we spin that elastic container in AWS down and spin up the new one. And once we basically do that, it's basically gone through its rigorous amount of checks, whether it's API test, performance performance tests and security tests, or whatever have you. Right, so I'm going to go over the specific details on how to set up your performance test suite with Gatling, as well as writing test simulation from scratch to test our APIs. But before that, I want to go over what Gatling really is. Right, so Gatling is an open source load testing framework that's written in Scala. This tool is used to measure the performance of the API that's being developed by the team. So with continuous integration, there's going to be several changes made, and those several changes will be incrementally made throughout a period of time. And then your API will be promoted to production, which will be in use by your users and come in heavy traffic by your users. Right. So one of the great things about Gatling is that I can write my performance test just like I write my integration test. As you mentioned before, your Gatling scripts can be integrated with CI tools such as Jenkins and others, if you prefer that. Right. The benefit we have when we do that is we get constant feedback from our performance test and we immediately can identify like, hey, should we roll this change back? Right, because this change doesn't meet the sla. Right? It doesn't meet our pass fail criteria as far as a threshold that we've set. And this is important for our organization because we continuously make changes to our API before we actually promote it to production.

Nice. So do you actually have performance criteria in your pipeline? So if someone does a release of a microservice, does it have like, if it doesn't meet a 99%, I don't know, like some sort of transaction timing threshold that it doesn't get rid in the main build, right?

So when we're developing and we get our design docs right, before we actually get into the core development of things, we have test skeletons that we write for our API. So meaning that we basically writing tests while the developers are developing. And another thing that we're doing is we're writing performance test plans and basically sometimes we're writing them before there's any SLA or anything even there. Right? In this particular scenario that I'm going to go over, we were rewriting a microservice, right? And we didn't have an SLA and we didn't have a threshold. So we actually needed those details before we released the production. And I remember in your Tech Beacon article, and the Tech Beacon article was, if I remember correctly, shift right, Testing microservices in the wild to tame DevOps, you spoke about using monitoring tools and setting up alerts. So currently we do the same thing. We're using New Relic and Splunk. New Relic is a tool that we use for application performance monitoring. This tool has helped us with various things such as transaction response, ever reporting, and much, much more. And transaction response for those that might not be familiar with that is we use transaction response in New Relic to gauge which requests are taking longer to respond. We use error reporting in New Relic to notify us if a system fails, as well as what the recovery was, how it's acting if when it's recovered, and helping us gauge if the API is stable enough to even make it to production. We also use these tools for like scalability testing, right? It's helping us gauge the ability of a system to cope with a higher volume of requests, data and users. So just to reiterate, let's get back to the pass fail criteria threshold you were talking about. The pass fail criteria for our tests at this point would be to maintain the same SLA as the current services in production. So we navigate to the transactions module in New Relic and we look for the throughput and average request per minute during high traffic hours. So let's just say a high traffic hour for us is 2:15pm we're going to go to the transaction module, New Relic. We're going to look for the average request per minute during 2:15pm and once I checked that it had an average about maybe 612 requests per minute. So we knew that the new service should at least have a threshold of 612 requests per minute without throwing a server error or showing a spike in Traffic. For those that don't know what a spike is, right, we can go to new relic and during high traffic times we can check if our containers in the cloud are basically overloaded or not. Now, fun fact is Gatling actually has several conditions that can be chained together to accomplish what you said. So the LTE threshold condition lets you assert the value of the metric. If it's less or equal to your threshold, you can actually check if it's greater than or equal to as well, et cetera, et cetera. Now, for each incremental software change that you're making and you want to publish the production, you can tag that git commit and you can run your Gatling test against that and you can validate if it meets your threshold and your sla. And if it does, you can promote it to production.

Wow. Very cool. So how long did it take you to get to this point? It sounds like it's a pretty mature. I love this approach. I've been advocating it for a while. So how hard was it to get buy in from your team to actually do all this?

So basically I brought this up during like a retro, that we should be performance testing all of the APIs to meet a specific SLA or threshold before we take it to production. And when I brought it up in the retro, we talked about how we could bake it into our release plan and then we talked about how we can test various features of it and we added it to our Sprint planning. It also has to do with an organization's timeline, how fast do they want to release to market, and what are the precautions they're taking to get there. So for us, downtime in a service. So we need these services to have high availability. We don't want any downtime, especially for farmers in the field. So for us this was a very important topic. I don't know if other organizations will think that's an important topic or want to invest the time up front to outline these procedures.

Now, how complicated was it for you to get set up and get started? Any lessons learned there for a quick start?

So basically, if you're setting up Gatling on your box, you just need Java 1.8 or Scala version 2.12 or above. If you're using Maven, you just need to add that IO Gatling to your POM xml. And if you want to run the test, it's just as easier as MVM Maven Gatling Colon test. And if you're using SVT in a Scala environment, you can, you could just write SBT Gatling tests and then you can run the test straight from the base directory in the SBT documentation. It will just let you know that the SBT plugin needs to be added to the file. Right, and that should live in your project directory. Other than that, once you're done with that, you basically have to bring in the imports, just like you would bring in the request import if you were doing API testing in pytest, just like you would require a GEM to be used if you're using RSpec, just like you would require an import to be used for rest assured, in your junit test, you would import the Gatling core and the Gatling HTTP imports. Gatling HTTP will allow you to load test the API. It supports all HTTP and HTTPs traffic and works primarily at the HTTP protocol level, meaning it's back end service driven, not UI event driven. Now, if you go for and prompt out to use the paid version of Gatling, you can basically do more of like a heat map or like a real scenario from the front end. And it could do more of a record and playback, but I'm actually not doing that because I'm using the open source version and I'm interacting more with APIs.

Cool. So it sounds like initially you're doing almost like a one user performance test. So you have a baseline, you have a microservice that's been running production. You know, historically it takes about 60 milliseconds. So therefore going forward, every other release shouldn't get worse than 60 milliseconds. Is that how you initially set it up? And then if so, do you ever do any sort of stress type testing?

Yes, that's exactly how I set it up in the beginning. But I want to demystify that a little bit because that's exactly what I do later on as the API matures, as it goes through rigorous testing. And when we tag that commit to go to production with git, the most important thing I do is I write a class that extends the Gatling simulation. Now, a Gatling simulation is a class that you can extend in your script, which allows you to do HTTP headers, protocol and scenario definition. We want to start off with the HTTP protocol definition, basically defining what your base URL is going to be and any URIs that go with that. Let me be more specific with what a URI is. A URI is Basically your endpoint. Www.testguild.com podcasts so/podcasts would be your URI and that will be prepended to the relative path in Your scenario definition. The base URL will also have some kind of headers, right? Like authorization, bearer, token, HTTP request, id, so on and so forth, which will be added to the request when you ramp up and ramp down your users. Right. Now, here's the real meat of your burger. The HTTP scenario definition, scenario structure change. Two function calls exec, which is describing an action, usually a request, such as sending a get request to version one of your endpoint, and the second one is pause. The pause simulates the think time between consecutive requests being made to the server. Now, those that are familiar with JMeter or Load Runner, various performance testing tools, they all have some way of processing think time or utilizing think time. To clarify, you invoke the exec function which builds an action, makes your HTTP request, then adds a pause for think time between the next request. An example of that would be we made a post request. Now, usually when you make a post request, you're writing something inside of a database. Then we invoke the exec function again to make a get request, which retrieves retrieves what we wrote into the database. We can pause many different ways and we can utilize Think Time many different ways inside of Gatling. Milliseconds is one of them. Or we can have random wait times, right? And I like random wait times because a real user session will have a user looking at what's on the screen and thinking about what he's going to click next. So I usually have random wait times in between my post and get requests of anything between one and five seconds. Or you could just basically pause for any amount of time, like three seconds, right? So we now have our HTTP header protocol and scenario definitions. We can add in checks like for response code such as 200 or 201 if it's a post request. Gatling has many assertions you can utilize to do various checks to see if your endpoint is behaving correctly. Let's just say if you make 60 requests per minute, the first 55 were 201 because you made a post request, and the 56th to 58th request it was 500. Gatling with these built in check assertions will let you know how many of these were 201 or 500. Now let's get a little bit into the ramp up and ramp down. The inject function in Gatling allows you to pass in the ramp user functions, which takes on an integer as an argument. An integer would be a number that you can pass into a function without using quotes. So a quotes would take string like quotes 10 end quote. Now, an integer would just be the number 10. You won't have to pass in any quotes with that. So this flexibility allows us to ramp up any number of users we want during a specific number of time. For example, I want to ramp up 20 users every 30 seconds. It's highly unlikely that a hundred people will log into my app at the same time. So I want to have ramp up scenarios such as that this sequence of injection steps can be processed sequentially and then you can add in assertions for average response time of whatever your expectation is. A common expectation for us is we want each request to be returned within 500 milliseconds. So there's basic example of that.

How do you handle dependencies? I know in microservices what's nice about it is, you know, it's so discreet, you know, it's this microservice. Here's the functionality for that microservice. You're testing that microservice, but in the wild, if there's other dependencies when you're doing performance tests, how do you know like another call from another microservice, calling into that service is going to not cause issues.

So basically what we do is we build test tooling around that. So a lot of things that have changed since microservices architecture has come out, service mesh architecture has come out. A lot of time now teams spend in test tooling writing robust scripts to stage data. We write these robust scripts to stage data on the fly. And you can call this like somewhat of a test setup before your test teardown. So we always have this test data stage and we run the performance test against the test data.

Cool. So I think you've already touched on this a little bit, but it sounds like a lot of times you may not have all the information you need in order to create a performance test plan. So any tips or techniques or tricks how to really curate a performance test plan from scratch?

So I would definitely encourage people to learn how to use new Relic, Splunk, Grafana and those kind of monitoring tools. You can go to a previous day or any previous amount of time and you can check user logs to see who is interacting with which service at what time and what's the average request per minute that it should sustain. That's the first thing I should do. You guys should do. Now let's just say you are at a startup or at a smaller company where you can't afford these tools. You can always run htop or tail the logs to see exactly which services are being interacted with and you can use that to create your performance test plan. Or I have an even better way of doing this. Launch a Chrome browser, log into your application Inspect element and go to the Network tab and see the interaction of services and then basically create a performance test plan from there. And that will be like a user flow, like a business flow. As far as your requirements for your application go, that would be an easier way to develop a test plan too, right? There's different ways of doing it. Depends on how mature your application is and where you're at in your software development process.

Okay Zabeer, before we go, is there one piece of actual advice you can give to someone to help them with their Scala Test Automation testing efforts? And what's the best way to find or contact you?

Anyone can reach out to me via email H A Q U E Z U B A I R gmail which is my last name. First name good resource is scalatest.org but I have a tutorial which is called a Beginner's Guide. Anyone can basically use that to spin up their environment and reach out to me if you have any issues getting acquainted with scalatest. I'll be more than happy to help. My advice for starting up with scalatest would be basically test early and test often. Divide your automated testing efforts. Make sure you have good test data that is staged, read the documentation and really dig into Rest Assured. Rest Assured has a ton of resources and you can add that to your Build SBT file and basically accomplish having a BDD type syntax inside of your scalatest repository.

Thank you Zubair for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a314 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 Source Lab's awesome products and services. And if you didn't know, I also have two other podcasts, one on security testing and one on performance testing. Also, make sure to check out Zabeer's session on Performance testing Microservices with Scala Test that I released last week. All you need to do is go to testguild.com P39 to hear that episode as well. 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.

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.