Do you include test codeunits with your BC extensions?

Running Dynamics 365 Business Central in the cloud, means that we always have a system which is running the latest version. Microsoft will take care of the upgrades of both the standard code and any installed extensions. Before upgrading and upon any new build Business Central is being tested by running 10,000's of automated tests in the test toolkit. This test is done every time they build their code, and it checks that the functionality in BC works as it is designed to work.

Besides the test toolkit covering the standard code, then all extensions available from AppSource comes with a test package covering at least 90% of the code. AppSource developers are also required to download the preview builds and make sure their extensions also work with the next update and even the next major release.

When it comes to extensions which are not build for AppSource, then there are no formal requirements.

If the extension is developed for only one customer, then in most cases you will have no requirement regarding test codeunits. Neither from the customer nor your employer. They primary see the time you need to spend, to create the automated tests as an extra cost.

So, why should you care?

Unless your extension is developed completely separate from the standard code, then you always have a risk that whatever you have used to tie your functionality into the standard has been changed. If you have subscribed to an event, then this may have changed (maybe new variables etc.), in a page extension/customization whatever you have used as your reference (i.e. addafter/before) may have changed. Of course, this does not change every month or in every release. If you have used integration events, then theoretical these should never change!

As everybody know, then changes do happen! The last two-three years we have all witnessed a fast stream of both new and a lot of changed functionality coming from Lyngby. Under the hood (so to say), we have seen even more changes coming from Microsoft's clean code efforts. Like redesigning codeunit 80, or their removal of codeunit 1.

And there is nothing in the air saying this will stop. We should also expect to see more design change when C/Side and the Windows client goes away within 1-2 years (as announced on Directions).

Having test codeunits will give you (and your company and customers) a basic assurance that the Business Central extension you have developed also works next month. If redesign or changes are required, then you know it before it breaks for your customers.

What does it take to make automated tests?

I am not going to tell you that it is easy to get started. For me its been a journey that started some years ago. I had the pleasure of my fellow MVP Luc van Vugt's NavTechDays pre-conference course on testing two years ago, where I learned a lot and also had a project where we implemented the test toolkit. But then I have been of to other projects, until I two months ago again were able to work on a project where it has to be applied. And I'm still learning.

It is not learning the special code required to write the test codeunits, that is the problem. Writing tests is actually very easy. The problem is really to define what to test and then figure out how you can test it.

You will also soon realize that some code is easy to test, while other parts may require you to write a lot of code or even mocks, before you will able to test it. You may also find that it requires you to learn everything you can, about design patterns and clean code.

If the extension was already developed, without knowledge of how the test toolkit, how to write test codeunits and clean code and design patterns, then your extension may be in a shape where it is almost impossible to implement it. At least not without refactoring your code heavily.

Ideally you would be using test driven development (TDD), where creating test cases and test codeunits is done before writing actual code. Do this "the right way", then it also involves the customer/system-owner, the analyst/consultant. Together you would be making the test plan, to specify and prioritize everything you need to test. The test plan basically becomes your primary design specification. Read more about it in Luc van Vugt's blog, his blog is the place to read about testing Business Central. This not something invented for Business Central, it's industry standards, which have been around for decades, just never really used much in our little NAV/BC corner of it.

My statement here is that, if correctly applied, then creating test codeunits may in fact speed up the entire project. You will use less time on manual acceptance testing and waist less time while waiting for consultants/users to test for feedback.

But the secret is to start as early in the development process as possible. You may easily use just as much time creating tests for an existing extension (not coded with clean code/design patterns), as you used to program it originally!

Who should pay for this?

Before answering this, then let's think "back" to the Navision days. If you created a customization to a customer, then it was created for that specific version and installation with the customer. If the customer, at a later time, wanted to upgrade to a new version, then they would have to pay you to bring thing the code into the new version. Even if the you could use MergeTool or later the PowerShell CmdLet's, then you still needed a full-scale test (with users) to ensure everything still worked. The result was that every upgrade was a huge and costly task, resulting in most customers staying on old versions for many years.

Visual Studio Code and Extensions have been seen as the answer to the upgrade nightmares.

Most of the times there would not be a problem, your extension will work, without any issues or even without having to be recompiled. But it is naïve to think that this would always be the case, especially when we talk about the twice a year major update.

Test codeunits and CI/CD (continued integration/continued deployment) is the foundation, which allows us to do it an automated, secure and efficient manner.

We must also answer a different question. How are we going to charge our customers for Business Central? When we talk cloud then there is really no recommend list price, except for the basic users. Each partner has to decide how they charge their customers, and which services are part of their price. That goes for the standard Business Central, as well as development of extensions made for specific customers.

Up-front Payment

The partners may decide to invoice development cost like in the NAV days, a once off price based on actual time used or fixed price.


The partner includes the development costs into the monthly subscription fee. The customer pays over time, together with the license.

The real question is who is responsible for making sure that the extension you made for the customer, also works next month? If you are their registered partner (CSP) in the cloud, then technically Microsoft is running it, but if their upgrade breaks your code, then it's not Microsoft they must contact, but you - the partner. So even if you did not charge them for creating test codeunits or testing every month, then it will be you fault – at least in the eyes of the customer. I do hope that this is a service you remember to include when charging your customers for Business Central?

The best solution is to always include "upgrades and automated tests" as a subscription services, no matter if the development was paid up-front or not. If already in a subscription, it is already a natural cost you should charge your customers every month. With or without test codeunits.

The answer is that the only one to pay, of course, is the customer. Either up front or better via a subscription.

As for the customer, depending on who "own's" the extension build for them, if their extension already has test codeunits, then it's going to be much easier for them to change partners. No partner would take on the responsibility for running an extension, which they have no way of know works correctly. At least not without charging a lot of money. But who would even consider moving from a partner, where everything works release after release and the quality cannot be questioned?


Personally, I'm not in doubt. If you create any extension for Business Central, which will run in the cloud, either now or later, then you must ALWAYS create covering automated tests.

Anything else would be like not having a car insurance. Or like selling a car without safety belts.

Today this may seem as something extra we are "giving" the customers, but I'm sure, that in a few years we have adapted the same industry standards, as everybody else in the IT industry.


Although testing is not the subject of David Singleton and my session at NavTechDays next week (Friday 9am), then it is certainly something that we are going to discuss as well. And I hope to see you there, if you are in Antwerp.


PS: Just to make it clear. I do not believe that having automated tests will catch all possible errors or make our systems flawless. It depends on how and what you are testing. But that is a very different blog post.

Comment List
  • You know Eric, We are "old farts" in the Navision World and that includes Luc van Vugt who is also in the Nav-World for at least 20 years. The question I generally ask myself about BC365 is the experience with the recent mayor release changes in the NAV World. As are:

    *The change from the DOS-Version to financials 1.0 around 1995,
    * The change from Classic to RTC 2009
    * The current change from C/AL to AL (or NAV2018 to BC365) currently

    Odds are that from the point of view of the customer (as well a from the developer) Financials 1.0 or NAV 2009 were not really a usable version. There were too many "child sicknesses" in these versions as you sure will recall. Conclusion is that it typically requires some 1-3 new releases after a dramatic change until two conditions are met: 1. Developers are fit with the new developement environment 2. Consultants are aware of the traps and loop holes of the new solution. Is that different with BC365? Are we really in the state to sell BC365 to real-live customers (unless they are ready to endure and pay for problems caused by a completely new environment nobody really has experience with)?

Comment Children
No Data