Inside Drupal Autotesting: Expert Insights from Aliaksandr Shabanau

Let’s be honest — bugs are annoying. Not just for developers, but for users, managers, clients, and everyone in between. When something breaks on your website or app, it slows you down, affects trust, and can damage your reputation. That’s why teams aren’t just building features anymore. They’re building systems that test themselves.

This is where automated testing comes in. It’s not just a technical tool—it’s a business advantage. When done right, it helps teams work faster, cut costs, and release better features with less stress. If you want to ensure that for your business, use Attico’s Drupal testing services.

In this article, we’ll break down what automated testing actually is, how it works, and why it matters far beyond your dev team. Along the way, we’ll share insights from our in-house expert, who’s been implementing automated tests in real-world Drupal projects for years.

Aliaksandr Shabanau, Senior backend developer at Attico, puts it as follows:

“Automated testing isn’t about writing perfect code. It’s about building confidence — so you can release without fear.”

What is automated testing?

In simple terms, automated testing means writing code that tests your code. Instead of manually checking whether your login page works or if your contact form still sends messages, you write a test once , and it runs automatically whenever needed.

These tests can simulate user behaviour, check business logic, validate outputs, or confirm that features still behave the way they should. And the best part? They run quickly and consistently without the risk of human error.

Aliaksandr explains:

“Imagine being able to run hundreds of checks in a matter of seconds. That’s what automation gives you. And those checks aren’t just for the new stuff. They validate everything that came before.”

This ability to constantly recheck the health of your system is a big deal, especially in fast-moving projects. When your team is pushing changes every week or every day, it’s nearly impossible to test everything by hand.

Where does it fit into the development process

A lot of people assume testing happens after development, like a last-minute check before launch. But with automated testing, it’s actually the opposite. Tests are often written during development alongside the feature itself.

As soon as a developer builds something new, they also write a test to confirm that it works as expected. These tests are added to the project’s codebase and run regularly, often through a CI/CD pipeline. Whenever someone pushes new code, the full suite of tests is triggered. If something fails, the developer knows immediately.

Aliaksandr compares it to design work:

“We treat tests like part of the product. You wouldn’t launch a feature without styling it properly, so why would you launch it without knowing if it works?”

This approach isn’t just faster. It’s safer. It helps catch problems early before they reach production. And it builds a culture of quality from day one.

The expert also points out:

“Tests don’t just verify new features. They protect existing ones. When you build something new, you’re not risking breaking what already works — because your tests will catch that instantly.”

Why businesses should care

At this point, you might be thinking, “That’s great for the dev team, but why should I care if I’m not writing code?” The answer is simple: because the cost of bugs isn’t just technical — it’s financial, operational, and reputational.

Let’s break that down.

1. Speed to market

Automated testing makes it easier to move quickly. You don’t have to pause everything for manual QA every time you ship a change. Instead, your team can deploy faster without cutting corners.

As our expert puts it:

“Speed doesn’t mean skipping checks. It means automating them.”

2. Lower long-term costs

Yes, writing tests takes time upfront. But it prevents expensive problems later. Fixing a bug in production is always more costly than catching it in development. With automation, you catch more issues early — and spend less time cleaning up later.

3. Improved stability

There’s nothing worse than fixing one thing and accidentally breaking another. With a solid suite of automated tests, you don’t have to worry. Your system gets checked from top to bottom with every release.

“It’s not about testing more. It’s about testing smarter,” he explains.

4. Easier onboarding

Automated tests become living documentation. They explain how the system is supposed to work. When new developers join, they can read the test cases and understand how different parts of the system behave.

“I’ve had cases where tests explained the business logic better than the actual documentation. That’s real value,” adds Aliaksandr.

5. Higher user trust

When your platform works reliably, people notice. And when it doesn’t, they notice that too. Automated testing helps reduce embarrassing bugs and gives your users a smoother, more trustworthy experience.

“If your user finds the bug before you do, that’s already a loss,” he warns.

6. Better developer morale

No one likes being on call for hotfixes every Friday night. Tests catch problems earlier, which means fewer emergencies, less stress, and more time spent on building new things instead of fixing old ones.

Why automation helps non-tech teams too

It’s not just your developers who benefit from a more reliable system. Your marketing team can roll out landing pages without wondering if forms will work. Your support team gets fewer bug tickets to handle. Your product managers can prioritise features instead of firefighting issues.

Automation creates a more stable foundation for every department. And that’s something everyone feels — not just the people writing code.

What kinds of tests are there?

There are different levels of testing, and each serves a different purpose. In the Drupal ecosystem, we often use four main types:

Unit tests

These are the smallest and fastest. They test individual pieces of code, like a single function or class. They’re isolated and don’t require loading the full system.

“They run in milliseconds, and they’re great for business logic,” says our expert.

Kernel tests

Kernel tests work with partial system bootstraps. They load essential services like the service container or database schema but not the full site. This makes them ideal for testing how components interact at a deeper level.

Functional tests

These are more like what the user would do. Functional tests simulate actions like submitting a form, editing a node, or navigating a page. They require a full Drupal install and can be slower , but they give you strong confidence.

Functional JavaScript tests

These are for frontend features. They simulate clicks, animations, and dynamic UI behavior using tools like WebDriver. When your site relies heavily on JavaScript, these tests become essential.

Here’s what our expert thinks:

“With the right test coverage across all four types, you’re covering everything from the deepest logic to the user clicking a button.”

What good coverage actually looks like

A common question we hear is: how much test coverage is enough? There’s no magic number, but a good starting point is to focus on critical paths — the parts of your system that users rely on most. These could be login flows, payment processing, or any feature that, if broken, would block people from using your product.

“You don’t need to test everything at once,” Aliaksandr notes. “But the things that break your product? Those should never go untested.”

From there, you build gradually. Adding more tests with every sprint makes testing part of your natural rhythm, not an afterthought.

And what about manual testing?

Manual QA still plays an important role. Automation can handle repetitive and logic-based checks , but it cannot replace the human eye.

Manual testing is still needed for:

• Visual appearance and design
• Accessibility
• Complex, real-world edge cases
• Unexpected user behaviour

As our expert puts it:

“We’re not trying to replace QA testers. We’re giving them more time to test things that actually need a human touch.”

Together, automated and manual testing create a well-rounded safety net. You automate what you can and let humans focus on things machines can’t yet do well.

Tools that power testing in Drupal

Drupal supports various QA frameworks. Here’s a quick look at some of the most commonly used ones:

• PHPUnit: Used for unit, kernel, and functional tests. It’s fast, flexible, and built into Drupal core.
• Nightwatch.js: Great for JavaScript and browser-based testing. Simulates real user actions on the frontend.
• Behat: Once widely used, now largely replaced by PHPUnit in most Drupal setups.
• Custom testing pipelines: Often integrated into GitHub or GitLab CI, with tests running on every push or pull request.

Here’s what Aliaksandr recommends:

“If you’re working with Drupal, PHPUnit is your best friend. It’s mature, supported, and lets you scale your test strategy easily.”

How to know if you’re ready

You don’t need to be a huge team or enterprise company to benefit from automation. In fact, smaller teams might benefit even more because time and resources are limited.

Aliaksandr sums it up simply:

“The moment your team starts asking ‘what might break if we change this?’ — you’re ready.”

Getting started is easier than you think. Begin with tests for the most important or most fragile parts of your app. Add more over time. Even a few tests can make a big difference.

The goal isn’t perfection. It’s confidence.

Making the case for testing in your team

Still not sure how to bring up automated testing with your team or leadership? Try starting small. Pick one problem that keeps repeating: maybe a form that breaks too often or a section of the site that’s risky to update.

As our expert advises:

“The best way to make the case for testing is to tie it to a real headache you’ve had to fix more than once.”

Once people see how much time one test can save, it becomes easier to get buy-in. From there, you can scale up your efforts and get everyone on board.

Final thoughts

Automated testing is one of those practices that seems complicated until you try it. Then you wonder how you ever worked without it.

It protects your product. It supports your team. It saves money, improves quality, and helps everyone — from developers to stakeholders — feel better about what’s being built.

Aliaksandr puts it:

“Testing doesn’t slow you down. It speeds you up by reducing fear.”

So if you’re building something that matters, invest in testing. Your users will thank you. Your team will thank you. And your future self will definitely thank you.