By Patrick Sieswerda, Senior Developer, Dynamics4Business, Feb. 18, 2026
Automated testing is not an exciting topic. It is not an innovation, not a game changer, nor is it a reason to pop confetti. But: it is something you just have to have in place. For us, automated testing is not an extra service, not a separate part of the portfolio and not a nice to have. It's hygiene. Just like version control, code reviews and documentation. If you don't do this, you are taking unnecessary risks, for yourself and for your customer.
What do we mean by automatic testing?
Automatic testing means that software checks itself for correct behavior. Established test scenarios are executed by code, not by humans going through the same path every time. Changes to the code are immediately checked to see if existing functionality still does what it is supposed to do. Not because we like it, but because otherwise errors won't surface until late or at the customer.
Why this should not be a point of discussion
In Dynamics 365 Business Central environments, we often see complex processes: financial entries, VAT calculations, discounts, integrations. These are exactly the parts where errors have a big impact.
Automated testing provides, among other things:
- Consistency - the same tests, every time
- Quick feedback - errors become immediately apparent
- Less regression - fixes do not break existing functionality
- Safe refactoring - enhancing code without fear
- Scalability - even with growth, quality remains manageable
This does not make your software better than anyone else's. It mainly prevents it from becoming worse.
But it takes time, right?
Yes. Automated testing requires initial investment and maintenance. Tests must be updated as functionality changes and they take time in the CI pipeline. That's not a drawback, that's reality. The question is not if it takes time, but when you want to spend that time: in advance in a controlled way, or afterward during disruptions, recovery work and explanation conversations.
Testing does not start with development
Automated testing only works well if it is already included in the analysis phase. Don't just capture what a solution has to do, but also How we prove it works.
Test scenarios and acceptance criteria form the basis for unit and integration testing. In the development phase, these scenarios are translated into automated tests, often together with building the functionality. Thus, every change is validated immediately. Not exciting. But sensible.
Case study: discounted sales invoice
A concrete real-world example: a Business Central extension that automatically applies a discount when posting sales invoices for customers in a specific customer group.
An automated test then checks, among other things:
- Has the invoice been posted correctly?
- Has the discount been applied correctly per line and in total?
- Are the customer, general ledger and VAT entries correct after the discount?
One test checks the entire process from input to financial processing. Every time.
Why we share this
Not because automatic testing is a differentiator. But because it shows how we deal with quality. As a BC partner and trusted advisor, we consider it our responsibility to reduce risk, not through promises, but through craftsmanship. Automated testing is simply part of that. No headline. No campaign. Just done properly.
If you’re unsure whether this is sufficiently embedded in your case, a good conversation is often clarifying in itself.