The thing that really sets apart Allure Report as a reporting tool is the fact that it integrates with pretty much anything. So much so that, to be honest, it might be difficult to keep track of all the adapters - especially considering that many of them are created by the community, so it's a networked effort. Hence the need for the awesome-allure project.
What is allure-awesome?
Inspired by awesome-js and awesome-python, we've created an awesome-allure list that should contain links to every important integration with programming languages, CI/CD tools and IDEs. The idea is simple - to keep track of a community effort, we need the help of our community. So use the list for your needs - or contribute! If you feel that some project is missing - take a look at the guidelines and post it in the list.
The important part here is that we will be reviewing and maintaining the list, which means that everything you find there has been approved by us. Say you need to set up reporting for Kafka on Kubernetes. Right now, what you have to do is google your way to some third-party tool that may or may not break your setup. In the awesome-allure list, you'll either find something that we've written ourselves, or something that we've checked and made sure that it's the best tool for the job, saving you the time and pain of doing it on your own.
In other words, awesome-allure is a collaboration between us and the community. The feedback between community demand for integrations and us planning for a language- and framework-agnostic tool has been an important strength of Allure Report over the years.
Allure Report is built for integrations
From a very early stage, the main contributors of the project went to great lengths to make integrations as smooth as possible. A lot of planning and thought went into the structure of the project, including the following:
- Code reuse. When you've written the first few integrations, you might thing that much of the code could be reused; but the further you get, the more it turns out that the common libraries you've created are not so common after all. This problem can trip you up in less-than-obvious places.
- Data format. The JSON-based format that Allure Report is using right now took probably a year of work to create.
- The plugin system. This, again, required tons of work and had to be maintained in order to provide backward compatibility.
Building Report this way, as a tool meant to bind with other tools, has been possible because of how it was treated by its community.
Allure Report exists thanks to the support of its community
In the first version of Allure Report, the initial authors of the project wrote just a handful of integrations - JUnit 4, Python and that's about it. The big overhaul that took Report from the first to the second version was necessary in part because the community made tons more integrations. The demand and effort of the community were what pushed the authors to their engineering decisions. And we continue to keep our ear to the ground in this regard - important projects and features developed by the community have been gradually introduced into the core of Allure Report.
However well-planned the basic structure of our tool is, writing an integration means months of work. And the reason why doing this work is possible is that we know there are several million people out there who have become used to solving all their testing problems with Allure and who need our efforts. Not only that, but the open-source nature of our project has helped us find people who specialize in writing integrations.
So this is the feedback that I've been talking about - a tool needs to be used to get better, and if careful thought is put into improving it, it will be used more. You can be part of either side of that feedback - run your tests with Allure, write code, and post on the awesome-allure list!
