Why I don’t recommend UI testing in AEM (even though I write tests for my own projects)

When customers or partners ask me, “Should we write UI tests for our AEM projects?”, I usually say, “No, probably not.” But here’s the twist: when I’m working on something like Optel Explorer or AEM Sidekick, I write extensive tests.

Sounds contradictory, right?

It’s not. It’s all about understanding the cost-benefit trade-off of testing and most importantly, knowing why we test in the first place.

Let’s start with the basics: Why do we test?

Testing isn’t glamorous but it’s the quiet force behind fast releases, fewer bugs, and happier users. We don’t test just to tick a box; we test to gain confidence. Confidence that our code works, that we can ship faster and that users won’t hit broken experiences in production.

But testing comes at a cost: time, complexity, maintenance, and infrastructure. So the real question becomes: Is the benefit of testing worth the cost in this context?

Think of testing like insurance. You don’t insure everything—you insure what’s valuable and vulnerable. Similarly, in software, we should test where the impact of failure is high and the cost of testing is low.

Let’s bring this to life with two contrasting examples.

Scenario 1: Backend Utility Library

Imagine you're building a backend library that’s used across multiple services. If something breaks here, the consequences are serious. A single bug could ripple across dozens of features. Fortunately, testing this kind of logic is straightforward. It can be done in isolation, without any UI, using fast and reliable unit tests. Since the logic doesn’t change often, the tests remain stable and require minimal upkeep.

In this case, the value of testing is high, and the cost is low. It’s a no-brainer; definitely worth the effort.

Scenario 2: UI Testing in AEM

Now picture writing UI tests for a visual component in AEM. A misaligned button or a slightly off layout might be annoying, but it rarely breaks the user experience. Setting up automated UI tests, however, is anything but simple. Frameworks like Playwright or Web Test Runner require significant setup, and the tests themselves are fragile - small, unrelated changes can cause them to fail. Maintaining them becomes a chore.

Here, the value is low, and the cost is high. In most cases, it’s just not worth it.

Why Any CMS Makes UI Testing Even Harder

Content Management Systems (CMSs) are designed for flexibility, not predictability and that’s exactly what makes UI testing in these environments so challenging.

Components are rendered dynamically based on authored content, which can vary wildly. Different authors structure pages differently, introducing inconsistencies that automated tests struggle with. What works locally might fail in CI/CD due to rendering differences or timing issues. And DOM structures change often due to styling or layout updates, breaking tests even when functionality is intact.

Unless you’re testing a critical user flow like login, checkout, or form submission - UI tests in CMS environments often become more of a maintenance burden than a quality safeguard.

So, should you test in AEM?

Yes, but strategically.

Focus your efforts on areas that carry real weight: backend logic, reusable libraries, critical user journeys like login or checkout, and integrations that tie systems together. These are the pillars of your application’s reliability.

On the other hand, let go of the urge to validate every pixel. Visual tweaks on content-heavy pages, components that shift frequently, or purely aesthetic elements rarely justify the overhead. They tend to break often, demand constant updates, and offer little in return.

Final Thought: Test with Purpose, Not by Habit

Testing isn’t a ritual. It’s a strategic decision. That’s why I write tests for my other projects but still advise others to think twice for writing tests in AEM. Because I know exactly what I’m validating, why it matters, and what I’m prepared to maintain. I’m not chasing perfection, I’m investing in stability where it counts.

In the world of Content Management Systems, where the UI is dynamic, content-driven, and constantly evolving, the cost of exhaustive UI testing often outweighs the value it brings. So instead of testing everything, focus on what truly matters.
Think in terms of impact versus effort. Validate what’s stable, critical, and cost-effective. Let go of what’s fragile, cosmetic, or constantly shifting.

That’s how you build AEM solutions that are not only reliable but agile, efficient, and future-proof.