Java Full Auto – Full functional automation in a single project
This is not an AI generated article!
Neither is the code in the GitHub repository that is provided in the article. This is, human to human, template to whoever enjoys the tech stack I do. But, being limited to Java/Selenium/Rest assured/Appium stack does not limit our general understanding and conceptual knowledge in this article. Java ‘Swiss knife’ or Java full auto solution is a way to save time on the projects where you need to start off quickly and get something presentable in sense of QA automation.
Imagine yourself, a QA/SDET guy on a project where things are hectic and requirements are just flying around. You may already have had a chance to experience that? Everything is happening so fast, constant change in requirements, not enough time to do proper testing of the software you are working on and still being constantly asked ‘when will we have that automation up and running?’ by your superiors. Now if you were to come up with a proposal for them, like ‘give me two weeks to do some research on what best suits our needs and set up a solution’ you would have most probably have been denied. I know I wouldn’t prioritize that over simple (and reliable) old manual testing when the house is on fire, so why should managers? Then, what do you do?
Template it!
I did it with the thought that, at least soon, I would not need to anymore and would be able to help the project, the manager, and myself by providing a quick and clean start to overall QA automation (for functional testing).
I started my research with one solution to all my problems in mind:
- Single project
- Web testing support
- API testing support
- Mobile testing support
- Shared code and integrations (DTOs, databases, services…)
- Local and distributed execution support
- Parallel execution
- Test tagging
- Reporting
By the time my research was concluded, I realized that I could not find this thing I desperately needed – one to rule them all automation solution template. Everywhere I searched was always either an API template, a UI template, or mobile automation template. Having all that in a single repository, using the same language, build tools, test runners, reporting and utility code could prove beneficial next time I get into situation earlier mentioned, which for a QA is very likely to happen.
So, I went for it!
First, I thought, since time is of the essence, I need to code fast. That is why I chose Java, not because it is the best out there (maybe it is, who knows) but because it was my comfort zone.
After choosing Java I knew I needed to make a hard choice: JUnit Vs. TestNG. I chose JUnit. Even if a very large portion of the community are TestNG fans, JUnit seems to be much more likable. I visited Testing Frameworks & Tools and saw that (at least Maven users) are much more lenient towards JUnit. Also, after JUnit5 release this choice is even more natural (at least to me)
After handling all high-level things, it is time to hit the target, talk about the real heart of this template – tests! To do so we need to granulate and talk independently:
- Selenium for Web
I won’t waste much time here, everyone in the QA automation world has at least heard of this. While many mistake it for a framework Selenium is suite of tools and libraries that help us automate web applications. Chosen simply because it has the widest community support compared to all other solutions.
- Rest Assured for API
If you chose Java, it would, somehow, come naturally to choose Rest Assured library to test your endpoints with. I have been using it for years now and its simplicity is just compelling.
- Appium for Mobile
As with most of the things in life, re-inventing the wheel is rarely a good idea. This is why I chose Appium, to go with what the community uses the most. Should you visit Appium official website you could read that Appium is an open-source project and ecosystem of related software, designed to facilitate UI automation of many app platforms, including mobile, making it not only an option to test your mobile apps with but much more, and since community is using it mostly for mobile apps automation we will too.
Now, at some point you will need to differentiate between these types, right? For some tests, on the other hand, you will need to reuse stuff (like DTOs, util methods, integrations…). This is, actually, the sole purpose of this solution. To have many managed by one. If I want to make an API call to speed up my Web or Mobile tests, why not!
2. Mobile tests
3. Rest (API) tests
4. Web tests (project structure by type seemed logical in the template but you may choose structure by feature, too)
5. Again, common for all but at test level only
How you distribute your tests has great importance! It is important because it affects your parallel execution needs. Here you would choose to run tests locally or to have them run somewhere remotely. Test distribution is a science for itself, and I leave it up to you to best match your needs, we will just state that both: remote execution and parallel test runs are well supported!
Tagging is essential in many ways, especially in multi-type testing solutions like this. So, for example, you know that you can run all tests at once (web, api and mobile). For Maven users this is as simple as mvn test command. But we also took care of tagging, so if you choose you may run only one suite of tests (I.e., mobile suite) and we do it by utilizing Test Tagging, already a part of the solution, as simple as adding an argument to the Maven command from before to get mvn test –Dtags=”mobile & regression”. Before this, of course, we tagged our mobile test with @Tags({@Tag(“mobile”), @Tag(“regression”)} and more about this you can read from the code or from the README.md file or from the image below.
Now, for the fun part – reporting! Allure was my choice and will be for the future it seems. Why did I include reporting? Remember that ‘when will we have that automation up and running?’ question? Well, so many managers either trust you enough or don’t care how you get through specifics, all they worry about is results. It is only natural; the end result is something we work for. This is why reporting for QA automation must be prioritized quite often. QA is so hard to sell sometimes so having metrics for grabs, like Allure provides, would help a lot and your manager would have new weapons in the sales arsenal to fight for more of your hours! These reports, included in this solution, can also be run locally as simple as running command mvn allure:serve or have them distributed somewhere because they are dockerized and have API support. If you run your web test and run the command from above you would get something like:
To conclude my elaboration and let you dig into the code I will just state the obvious – we all love to cut corners, sometimes because we are pressed by our deadlines and sometimes just to ‘work smart’ and finish early. Either way, having something to save time is always good!
