Frontend at trivago

Testing your functionality is important, but what happens if other factors come into play? In this blog post we show how trivago handles non-functional testing for every commit and how we scaled it.

trivago believes that a sustainable Open Source ecosystem benefits developers, companies, and users alike.

A while ago we decided to Open Source our JavaScript framework, Melody, which we have been using since 2016. We designed Melody to be fast, memory efficient and to be flexible enough for the future.

Filtering is an important way to find what you're really looking for, so why should we be okay with some users not being able to access them? We're not, so we did something about it.

We were not as happy as we could be with out Cucumber test reporting solution - so we decided to build a new and shiny one from scratch.

How accessibility came from being neglected to being an important part of what we do at trivago

trivago has decided to sponsor Webpack with a monthly contribution of $10,000 ($120,000/year). We hope that this will help to secure the continued innovation of the project.

Our first [right-to-left platform](https://www.trivago.co.il/) was released in 2014. We had developed a solution to generate right-to-left CSS with Sass mixins and variables as we have [described](https://tech.trivago.com/2015/04/27/right-to-left/) in a blog article. We used this approach for nearly 3 years but recently migrated the right-to-left CSS generation from pre-processing to post-processing with [RTLCSS](http://rtlcss.com/). With this article I would like to share the reasons for the migration as well as our experiences and lessons learned.

Running Cucumber scenarios in parallel can be tricky, especially when a custom test runner is used. That's why we created Cucable - a Maven plugin to split test scenarios into smaller chunks that can be run at the same time.