Like any other code, AL code can be flawed and break during refactoring. To prevent manual testing, each time you make the smallest change in code, it is necessary to write Dynamics 365 Business Central AL automated tests. Dynamics 365 Business Central AL automated tests are pivotal to ensure that your code works correctly after refactoring or addition of new functionality.

In this article, we are going to talk more about how you should structure your Dynamics 365 Business Central AL automated tests instead of the code logic itself.

Prerequisite

If you are using Docker as a platform where to hold databases meant for development, you will first need to import Testing toolkit. This is necessary so that you would have access to Assert codeunit. Assert codeunit is used to set conditions that check whether your code works as intended or not.

Follow these steps to import Testing Toolkit to your container:

1. Open PowerShell.
2. Enter command “Import-TestToolkitToNavContainer <container name>”.
3. Restart container or generate symbols any other way.
4. Download new symbols to your AL solution.

Start writing Dynamics 365 Business Central AL automated tests

Now you need to write all Dynamics 365 Business Central AL automated tests in separate codeunit, and to be able to do that, you need to set codeunit’s subtype to Test.

Each separate test needs to have an indication that it is a test. You can indicate that by adding [Test] attribute on top of procedure.

The rest of the codeunit follows the same structure as regular codeunit, except for Assert before the end of the procedure.

Now you can declare Assert codeunit as a local or global variable.

This code, inside procedure, is used to set up the test itself. What goes into it depends on what exactly you are testing. In this example, the code check’s whether autofill code works correctly. It does that by initiating new entry, entering a value to “CodeField” field and activating OnValidate trigger. Then Assert checks if the field is not empty. The text “Field is empty” shows only if the test fails. This is the code bit that this test is testing:

You can also create procedures that are not tests in tests codeunit. Just simply don’t indicate that it is a test, therefore, I recommend to leave tests codeunits only for tests.

Run Dynamics 365 Business Central AL automated tests

In order to run Dynamics 365 Business Central AL automated tests that you have written, you have to publish your application, then go to “Test Tool” page, upload all “Test” codeunits and run them from there. The easiest way to access this page is to configure your launch.json so that startup page would be 130401.

When publishing your extension, you will be directed straight to the testing page, where you will need to upload all test codeunits.  Complete this action by pressing Get test codeunits button:

When uploading all codeunits, you can either run only selected ones or all of them at once.

As you can see, next to failed test there is text, which you write in Assert. Additionally, all the changes made to the database, for example, new entries created, are deleted after all tests are done.

How you should write Dynamics 365 Business Central AL automated tests

Let’s start with codeunits themselves. A good practice is to dedicate the whole codeunit to one part of your solution. You can split Dynamics 365 Business Central AL automated tests to different codeunits by code functionality, making tests library easier understandable and maintainable.

So, let’s say your solution creates new entries and post’s reports, then you create two different codeunits, one to test the functionality of entries creation and second to test posting functionality.

Inside these codeunits, you create tests themselves. Each test name should have an informative name, meaning, it should talk for itself. For example, if this test checks if a solution actually creates a new empty entry, then the name of this test should look something like this CreateNewEmptyEntry_Test. Some names can get really long, but don’t worry about that, it’s better to have longer, more precise names rather than short ones.

Your Dynamics 365 Business Central AL automated tests have to be specific, it should only be testing a certain part of your code and nothing else. Also, it is important to mention that it is always better to test each part of the functionality. For example, let’s say we have a table with three fields and a function in codeunit, which creates a new entry and fills the fields with random data.

We need to make a test to check this functionality so we have to create a codeunit for this whole functionality. The first test is to check if entry is created at all.

Then we need a test to check whether a value was added for the first field.

Finally, it is important to write a test to check if values were filled in the other two fields.

Divide your test solution to the smallest possible parts, it has to cover as much code as possible. It is recommended to write more than one unit test for each part of the code covering as many scenarios as possible. That way you not just stop possible bugs appearing after refactoring, but you may find bugs that you did not expect.

Your Dynamics 365 Business Central AL automated tests should be independent of any exterior programs or files. If it is not possible to avoid using an external file, try to find a way to create a dummy file inside the test and feed it as a real file to your solution. If your solution need’s to call for exterior services, create dummy services inside your test.

If you want your Dynamics 365 Business Central AL automated tests to have the maximum efficiency, it’s a good idea to make many “hooks” to which your test could attach to. That way you could test a tiny part of a code, instead of running the whole program, just to test, whether or not a value was added to the field.

Hooks can be described as procedures that are global and can be called from a test itself. Another definition of hooks is extra procedures that call a procedure which you want to test.

Conclusion

Let’s repeat the most vital steps for writing an efficient test:

1. Create codeunit for each functionality.
2. Name your unit tests meaningfully.
3. Divide your code functionality to smaller parts and test each part individually.
4. Make your solution code easily accessible for tests.

All in all, sticking to the steps mentioned above will help you to write codeunits with Dynamics 365 Business Central AL automated tests, that will last a lifetime for your solution. How can you tell that your test is good enough? If your test doesn’t need fixing each time you make a change and break when you make a mistake, you can tap yourself on a shoulder! Don’t forget, practice makes perfect, and if you don’t have time to practice enough, leave it to professionals. We are always ready to help with any type of Microsoft Dynamics NAV Upgrade / 365 Business Central Upgrade!