Business Central automated testing that catches breaks before users do

Why manual testing stops keeping up

Business Central online gets two major release waves a year, with monthly updates in between. Add your own extensions and a few marketplace apps. The combinations that could break then grow faster than a finance team can click through on a Friday afternoon. Something gets missed.

Manual checks also drift, so Business Central automated testing gives you a steady baseline. People test what they remember. They skip the awkward cases and rarely write down what they did. A test suite runs the same steps each time and reports pass or fail. That frees your users to look at the new features instead of rechecking old ones.

AL test codeunits: Business Central automated testing in code

The AL language has testing built in. A test codeunit holds test functions that set up data, run the code and assert the result. Test pages drive the user interface without a browser. Handler functions answer confirmations and messages, so tests run on their own. No screen is needed.

Microsoft publishes test libraries that create customers, items and documents with valid setup. That keeps tests short. We write tests beside each extension we build. Examples are the posting rule, the price calculation and the check that must block a bad entry. They run from the AL Test Tool page or a pipeline.

Page scripting for end-to-end flows

The page scripting tool in the web client records a user's actions and replays them. A purchasing lead can capture how to create an order, receive it and post the invoice. After an update, the lead replays the recording to confirm that each step still works. Replays take moments.

Because it needs no code, it suits acceptance scripts that the business owns. We help your key users record the flows that matter most. We add checks that compare values on screen. Then we store the recordings in source control, so nobody loses them on a laptop.

Business Central automated testing before every release wave

Microsoft makes each major version available as a preview environment ahead of release. We point the test suite at that version. We compile extensions against it, run the AL tests and replay the page scripts. Failures arrive as a list with the step and the error. Fixes start straight away.

The same run happens in a build pipeline whenever a developer changes code. So a fix that breaks something else is caught at once. For speed checks, the Performance Toolkit simulates several users who run scenarios together. It reports timings that you can compare between versions. Slowdowns show up early.

How much testing is sensible

Not everything deserves a test. Microsoft tests standard Business Central, so repeating those checks adds little. Effort belongs on your custom code. It also belongs where extensions meet, and on the handful of flows where a failure stops shipping or payments. Those come first in every plan.

For Business Central automated testing, we start small. A smoke suite proves that posting works across sales, purchasing and inventory. Then we add tests for each custom rule. The suite grows when a bug turns up. We add a test that reproduces it before the fix. That habit keeps the suite useful without making it a project of its own.

Business Central automated testing FAQ

Can Business Central automated testing run in production?

No, and it should not. Test codeunits and the test tools are meant for sandbox and container environments, because tests create and post data. We run them against a sandbox copied from production. We can also use a clean environment with demo data. Either way, your live books stay untouched, and your users see nothing odd.

Do we need developers to use page scripting?

No. Any user with the right permission can record and replay in the browser. A consultant helps with structure, stable test data and checks. But the scripts can belong to your process owners, and that is the point. They know the flows best. So the people who run a process also decide what a pass looks like.

Will Business Central automated testing replace user acceptance testing?

They replace the repetitive part. People should still judge whether a new process fits the business, which a script cannot do. Once users accept a flow, we record it. Then nobody has to repeat the same acceptance by hand at every update. That saves time and keeps the quality steady.

Can you add tests to an extension another firm wrote?

Yes, provided we have the source code. We read the extension and write tests around its main behaviors. Then we run them in a pipeline. This is a common first step when we take over support. It makes later changes safer, because a break shows up as a failed test before it reaches your users.

What is the Performance Toolkit in Business Central automated testing?

The toolkit simulates concurrent users who run defined scenarios. Then it records how long each one takes. Teams use it before go-live with large data. Also, it helps when you compare timings before and after an extension change or a new version. Run it in sandboxes only. We read the results with your team and flag any step that slows down.

Related development pages

Testing sits beside development, pipelines and update planning. These pages cover the connected work, from how extensions are written to how a sandbox is prepared. If you want Business Central automated testing for your own extensions, the contact page is the place to start the talk. For the product detail, see Testing the application in Business Central.