Read Streamlining GraphQL Service Testing with Karate

Streamlining GraphQL Service Testing with Karate

Over the last year trivago refactored the existing GraphQL monolith and moved to a microservice architecture, in what is also known as a federated setup. Federated GraphQL, as championed by Apollo, represents a significant shift in how companies architect and scale their GraphQL ecosystems, especially when transitioning from monolithic designs to microservice-based architectures. In a federated setup, each microservice maintains its own GraphQL schema, relevant to the domain it serves. These individual schemas are then seamlessly stitched together into a unified gateway. This gateway serves as the single access point for clients, enabling them to query data across multiple services as if it were coming from a single, monolithic GraphQL API. Such change involves also a completely new approach to the test and delivery, with the goal of empowering developers to quickly and safely deploy to production autonomously.

Read QA Meetup - 2nd Edition: Presentations and Recap

QA Meetup - 2nd Edition: Presentations and Recap

At trivago, tech meetups are one of our favorite formats to learn and exchange knowledge. In April, we hosted the 2nd edition of the QA Meetup, which turned out to be a great success. The event attracted over 65 attendees from various roles and companies. The evening was filled with inspiring talks by several talented QA experts. Attendees were sharing insights, asking questions, and soaking up knowledge. To make things even more exciting, there was a competitive quiz that got everyone on their toes, and a magic show by one of our speakers that completely amazed the audience.

End-to-end tests retry strategies

Why should you retry all tests on failure? Why not? This article will not go into details, listing pros and cons of each approach. There are already enough resources on the Web about the topic, listing valid points for both opposing views. As trivago Hotel Search frontend QA team over the last years we tried to stay away from a brute-force retry policy for failures and we rather tried to execute test retries only in selected cases. Recently, when we switched to a Continuous Deployment approach for our new frontend Web application (which empowers developers to merge and release some pull requests autonomously), we faced a greater need than before for understandable and stable test results. Due to that, showing as few “red flags” as possible for the automated checks on pull requests became even more important to ensure enough confidence in test results and to avoid slowing down the software development life cycle. The requirements and the balance between deterministic results and success ratio shifted, at least in some cases.

Read Cucable Maven plugin for parallel execution of Cucumber scenarios

Cucable Maven plugin for parallel execution of Cucumber scenarios

At trivago, we are using an in-house developed Selenium framework based on cucumber-jvm to run automated browser tests. As the test suite increased (the time exceeded 45 minutes for a full run), we were looking for ways to move away from sequential towards parallel execution. For Cucumber, there are actually not that many options available: