The Real Cost of Not Testing Your E-Commerce Shop

There is a conversation we have often with e-commerce teams, and it usually starts the same way.

The shop works. Plugins are running. Orders are going through. And when something needs checking before a release, a developer clicks through the flow, it looks fine, and the update goes live. So why would you invest time in automated testing?

It is a fair question. But the way most teams frame it, as an added cost, gets the maths wrong. And once you see it differently, it is hard to unsee.

Manual testing is not free. It just feels that way.

When you ship a plugin or a custom integration without automated tests, you are not avoiding the cost of testing. You are paying for it differently, every single time something changes.

Shopware releases an update. A dependency shifts. A payment provider updates their API. Each time, someone has to manually go through the same flows again to make sure nothing broke. That adds up quickly, and human time is almost always the most expensive line item in any project.

The logic flips when you think about it over the lifetime of a plugin. Automated tests are an investment that pays back every time you run them. The first update, the tenth update, two years from now when half the team has changed. The tests keep running. The manual clicking does not go away on its own.

What a release looks like without CI/CD

For a lot of e-commerce shops, a major platform update looks something like this. You block out half a day. You make a backup. You mirror the old files somewhere in case you need to roll back. You apply the update, run through a checklist manually, disable maintenance mode, do another round of testing, and then hope nothing slipped through.

Every release is an event. And every event carries risk.

With a proper CI/CD pipeline in place, that same process becomes something else entirely. Build, deploy, maintenance mode handled, done. What used to take half a day can take closer to half an hour, with maybe ten minutes of actual downtime for customers. More importantly, it is reproducible. The process is the same every time, which means the risk is predictable and the team is not flying blind.

That is not just a developer quality-of-life improvement. That is operational reliability for the business. When a release stops being a stressful event and becomes a routine one, the whole team moves differently.

The three layers of testing

Automated testing usually works in layers, and understanding what each layer does makes the whole thing a lot less intimidating to get into.

Unit tests cover small, isolated pieces of logic. A function. A calculation. A data transformation. They are fast, you can run hundreds of them in seconds, and they form the foundation of a solid test suite. If your shop converts order data into a format your ERP expects, unit tests make sure that conversion keeps working correctly even as Shopware versions change around it.

Integration tests check whether different parts of the system work together. Whether an order placed in Shopware actually arrives correctly in your ERP. Whether the fulfillment process gets triggered. Whether the data that leaves one system is the data that arrives in the other.

End-to-end tests simulate a real customer session in the browser. Searching for a product, adding it to the cart, going through checkout, completing the order. These are the most expensive tests to maintain, so you keep them focused on the paths that matter most, the ones where a failure directly costs revenue.

A healthy test suite has a lot of unit tests, a reasonable number of integration tests, and a small, deliberate set of end-to-end tests covering the flows that cannot be allowed to break.

Where to start if you have an existing project with no tests

Looking at a large, mature codebase and thinking about where to even begin can feel paralysing. The instinct is to want to test everything before you can feel safe. But that is not how it works in practice, and it is not the best use of your time.

For an existing project, start at the top. End-to-end tests on your most critical flows first.

• Can customers find and search for products?
• Can they add to cart and complete checkout?
• Do orders reach your ERP correctly?
• Does your fulfilment process get the right data?
  Get those covered. Then work downward into integration tests for your external connections, and unit tests for the logic that those connections depend on. Make sure all new code is tested from the start. The coverage grows with the project rather than trying to catch up to it all at once.

For new features specifically, test-driven development is worth considering. The practice of writing the test before writing the code forces you to think clearly about what the code is actually supposed to do. It sounds like extra overhead, but developers who do it consistently find that it produces cleaner, more focused code because the test acts as a specification. You are not guessing what the function should return. You have already decided.

When a bug appears anyway

Testing does not eliminate bugs. That is not the promise. The promise is that it changes how you respond to them, and how many of them come back.

When a bug is found, the right response is two things: fix it, and write a test that covers that specific case. This includes edge cases, not only the happy path where everything behaves as expected. A test that only checks the ideal scenario is a test that will miss the thing that actually goes wrong in production.

Every bug that gets a test attached becomes a bug that cannot quietly reappear three months later when someone updates a dependency. Over time this compounds. The test suite grows not just with new features, but with every problem you have ever solved. The codebase becomes progressively harder to accidentally break, not because it is perfect, but because there is an expanding safety net underneath it.

The part that is hardest to put in a spreadsheet

There is a benefit to testing that does not show up neatly in time-saved calculations, but it might be the most important one in practice.

Without tests, releases run on a kind of quiet hope. You push the code and hope nothing broke. You go through the checklist and hope you did not miss anything. That uncertainty accumulates. Updates get delayed because nobody wants to be the one who broke checkout. Releases start feeling high-stakes even when the changes are small. Teams become reluctant to touch things that are working.

Tests give you proof. Not that the code is perfect, but that it does what it is supposed to do. You can run them before a release, after a dependency update, after a refactor, and see in seconds whether the behaviour you expected is the behaviour you have. That proof builds confidence, and confidence is what lets a team move at the pace the business actually needs.

There is also something worth saying about what this does for individual developers. Imposter syndrome is common in software, regardless of experience level. Knowing your code is correct because a test says so, rather than because you believe it to be, is a different kind of reassurance. Tests are not a crutch. They are evidence.

Is your release process the bottleneck?

Most teams that are not testing do not think of themselves as teams that are not testing. They think of themselves as teams that test when it matters, manually, before releases, carefully. And for a while, that works.

The moment it stops working is usually not dramatic. It is gradual. Releases start taking longer. Plugin updates get pushed back because nobody is sure what might break. The checklist gets longer. A developer who knew where all the bodies were buried moves on, and suddenly everyone is a little more nervous about touching certain parts of the codebase.

If any of that sounds familiar, the problem is usually not a specific bug or a specific gap in the team. It is the release process itself, and the lack of a safety net underneath it.

This is a large part of what we work on at Kiwee: helping e-commerce teams build deployment pipelines that are stable and reproducible, setting up staging environments that actually reflect production, and putting automated tests in place for the flows that matter most. Not as a one-time project, but as part of building a shop that can actually change without everything feeling fragile.

If you are heading into a Shopware migration, dealing with integrations that feel risky to touch, or just want to understand where your current setup is most vulnerable, we are happy to take a look.

[Talk to us about your setup →]

• CD/CI
• DevOps
• Testing