Ramona Schwering

“It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger. This situation is a nice allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing, but still ending up with tests failing to deliver you any value at all? Tests who are feeling like a pain to deal with?

When writing frontend tests, there are lots of pitfalls on the way. In sum, they can lead to bad maintainability, slow execution time, and - in the worst-case - tests you cannot trust. But it doesn’t have to be that way. In this session, I will talk about the common mistakes developers make, at least from my experience. And of course, on how to avoid them. Testing doesn’t need to be painful, after all.

A test can also be such a liar: Unreliable tests are living nightmares for anyone who writes automated tests or just pays attention to their results. Sometimes they pass, sometimes they don't, and therefore do not give a valid statement about the state of the software. In the worst case, they can damage the credibility of the entire test suite. It doesn't matter whether you write unit, integration or end-to-end tests, you can encounter them in any way you can think of.

I've spent hours and hours on such tests, and I want to share my journey and the lessons learned from them: So that together we can avoid or even get rid of these nightmares.

There are so many traps one can fall into when creating automated tests. In this episode, Ramona Schwering, a software developer with a passion for testing, shares her tips to help you avoid some of the most common testing traps. Discover strategies to prevent slow tests, painful-to-maintain-and-debug tests, and tests that have no value. Stop wasting valuable time debugging and maintaining flaky tests. Listen up!

Ramona Schwering zeigt, wie einfach es ist mit Cypress.io End to End Tests zu erstellen und so Anwendungen zu prüfen.

You should always write a unit test for any function change. It guarantees that your written code works and that a third party developer does not destroy the functionality with his code in the future.

Having good test coverage means we can be confident that we can deploy stable software without requiring additional manual testing.

We use Jest as our test framework. It is a solid foundation and is used by many developers. This small video will show you how to write those unit tests for the administration in Shopware 6, on the component test level.

Our daily work at Shopware, but also at agencies, ends up in the hands of people who trust us not only to have done our best, but also that it works. It is our job to instill this trust. Fortunately, we developers have a way to ensure something like that: Testing! Let's discover in this talk how we approach automated testing in Shopware, how far we have come on this journey, and what we have gained so far.

When it comes to UI testing, some developers tend to be reluctant a lot. Are those tests slow, flaky, hard to write and maintain?

Cypress.io (or Cypress for short) is currently getting a lot of attention when it comes to end-to-end testing. Especially in JavaScript environments Cypress.io seems to be slowly gaining acceptance. It does a lot of things right and is preferable to selenium-based approaches in my opinion.

In my session, I want to introduce Cypress to you and explore its possibilities by writing first tests for the SymfonyWorld website (or any other if I need more test cases) - so that we can overcome those concerns together.

Ramona arbeitet als Quality Assurance bei shopware

Wir unterhalten uns mit Ramona über Test Driven Development im Frontend.