Allure Start: prefab tech stacks, zero effort

The variety of modern testing frameworks, libraries, etc., can be overwhelming. Setting everything up takes time, and if you want to try many different solutions to make an informed decision, you might not have that time. Don't worry, though - there is a solution.

A menagerie of tools

There was a time more than a decade ago when a testing framework was a rare beast: JUnit appeared in 2002, and for a while, that was pretty much it. Along with Extreme Programming and TDD, it did a lot to help people realize the importance of tight delivery cycles and automated testing. People started making ports of JUnit left and right, like CppUnit for C++ or NUnit for .NET. Every language developed its own framework.

Then, problems with those first frameworks became apparent. TestNG was created to overcome the shortcomings of JUnit. Other instruments appeared, like Cucumber. At the same time, build tools were being developed, like Gradle and Maven (which also first appeared in 2002). As a result, by now we have a pretty impressive menagerie of tools.

Why it's bad for you

This presents a problem. Think of how much variation you can have in your stack. There's the programming language (which can have different versions, often not backward-compatible), the build tool, the test framework, and then the libraries (WebDriver, Playwright, or whatever).

Additionally, writing in-depth documentation takes time, and many tools might have very little of it. Also, they might not have support in IDEs. All of this means that switching technologies is

• something you have to think about often
• very time-consuming

Here are some examples:

1. Suppose someone on your team or your user comes to you with a problem. In their particular setup, pytest version x.y.z doesn't work with stuff that functions perfectly well in another setting. Is it just them? To understand that, you'd need to replicate their stack. Even if you've already worked under that exact setup, it will take you a few hours to refresh all the dependencies and ensure everything is working. And what if you have to set up everything from scratch?
2. Suppose you want to test some frameworks and decide which to adopt. Maybe you work with Selenide and wish to try Playwright or Cypress, experiment with Python, or figure out how to write API tests in Ruby. That's natural - the number of frameworks keeps growing, so we all want to keep up with the technology and adopt the good stuff. As things are today, you'll have to spend 2 weeks fully setting up Cypress, then 2 weeks with Playwright, and only then will you learn which is best.
3. Suppose you're sitting on a really old version of Cucumber, and you want to know how difficult it will be to upgrade to the latest version. How will you know without upgrading?
4. Suppose you're new to the industry; having just learned to write selectors, you're eager to get on with it. What you don't know is that before you write anything, you'll spend several frustrated days setting up the IDE and all the dependencies.

How to beat it

That's where Allure Start comes in. It assembles your tech stack for you! You go to https://allurereport.org/start/ and choose a selection of tools that you need for your project. The system then generates an archive with everything you need, including documentation. The current version is still raw, but in essence, this is what it does:

For instance, if you generate a project for Cucumber with Java, this is what you'll get in your file:

.  
├── .mvn  
│   └── wrapper  
│       ├── maven-wrapper.jar  
│       └── maven-wrapper.properties  
├── src  
│   └── test  
│       ├── java  
│       │   └── org  
│       │       └── example  
│       │           └── cucumber  
│       │               ├── steps  
│       │               │   ├── RestSteps.java  
│       │               │   └── WebSteps.java  
│       │               └── CucumberTest.java  
│       └── resources  
│           ├── features  
│           │   ├── labels-rest.feature  
│           │   ├── labels-web.feature  
│           │   └── milestone-web.feature  
│           └── allure.properties  
├── mvnw  
├── mvnw.cmd  
└── pom.xml

Soon, this will also include instructions on how to develop your project further. The stack of tools you get is guaranteed to work: we verify it on a CI before handing it off.

The folder you get from the archive can be opened in your favorite IDE as a new project. Actually, you can think of the whole thing as "New project" in IDE - but way more configurable. Basically, Allure Start is a playground where every combination is a few clicks away, and you can experiment to your heart's content.

A similar solution exists called Spring Initializr. What we're building will do the same thing - but for testing.

The advantages of being polyglot

Think again about how many different permutations your tech stack can have - and yet, there is one position that doesn't have to change. That's the reporter. Allure Report was built to handle this great variety of tools. No matter what language you're using or what test framework, the representation in Report will be the same: steps with natural-language descriptions, attachments, and stack traces for errors.

There's a list of everything Report integrates with here - the test framework page alone has 35 entries. Before, setting up an integration with any of those on your system would take some elbow grease - you'd need to fiddle with settings for a while before you could run stuff. But now, Allure Start takes care of everything for you, and you get everything pre-made.

Conclusion

The modern testing tech stack is incredibly variable, and you can find all kinds of permutations out there. This limits the number of people in the community who have worked on a particular permutation, makes problem-solving more difficult, and complicates experimenting with new tools.

Allure Start helps you try out different combinations of tools error-free and quickly, with just a few clicks. This means:

• Less time spent on decisions to adopt or upgrade technologies
• Way quicker diagnosing of technical problems on uncommon tech stacks
• Lower barrier of entry for people who are just beginning to learn test automation

Try it and tell us what you think!