Back in 2016 at trivago, we were building a new Selenium-based test framework with Cucumber, but the standard reporting tool wasn't quite fitting our needs. It showed lots of information, but finding the key details about which scenarios failed and why meant digging through charts and stats that weren't really helpful for our workflow. During a company hackathon, I decided to build something more focused on what we actually needed to see.
I used Cucumber's JSON output and some templating to create Cluecumber—a cleaner way to view test results that puts the important stuff up front. It worked well enough that we open sourced it with company backing, and eight years later it's had about 90 releases and is being used by testing teams around the world. It's been rewarding to see something that started as a weekend project actually help other people solve similar problems.
This talk covers the technical choices behind Cluecumber, but focuses more on what I learned from maintaining an open source project. From handling feature requests and common questions to keeping code clean while adding new functionality, plus the benefits of company-backed open source for everyone involved. I'll share why sometimes building your own solution makes sense, what works well for creating tools people want to use, and some insights from eight years of project maintenance.
Key takeaways:
- Understand why clear and concise reporting of test results is beneficial for all parties of the software development lifecycle
- Learn about when and where our test reports help in further exploratory testing and bug tracking
- See why it can be better to reinvent the wheel instead of going with using existing ones
