How-To Build Automated Testing for Microsoft D365 Business Central?

September 5, 2018

Let’s kick off with the Automated Testing on Microsoft D365 Business Central. If you are going to publish your app on Business Central, there are list of things you must complete before submitting it for validation. The checklist is available here https://bit.ly/2KfonXA 

A major requirement to submit an app on Extension is that you must include a Visual Studio Code test package with your extension. The test package must include at least 90% code coverage. 

In this blog, let’s explain how automated testing can be achieved with a simple example: 

Step 1: Table Extension for Cust. Ledger Entry 

First create an app extending customer ledger entries to auto populate all 6-shortcut dimension when Sales Document is posted. Here is the snapshot of the tableextension for Cust. Ledger Entry: 

table-extension
Table Extension for Cust. Ledger Entry 

Step 2: Subscribing the event 

Following AL Code subscribes “OnAfterCopyCustLedgerEntryFromGenJnlLine” event exposed from Cust. Ledger Entry Table. 

subscribing-the-event

Step 3: Transferring Data to Customer Ledger Entry from Sales Document 

The figure below captures the procedure to transfer all shortcut dimension to the Cust. Ledger Entry table 

transferring-data

Step 4: Defining Dependencies in app.json 

So, if you use above AL Code, we have an app ready. Now you can start up with the new project for the automated test functionality. 

It is important that you must separate the extension and the tests into separate projects. Create new project in Visual Studio Code and define the dependencies in app.json file. Moreover, App ID, Name, Publisher and Version must match with your base application. 

Defining Dependencies

Step 5: Downloaded Symbols 

After setting up the dependencies value, you will have to download the symbols from the base project. So, this means you will have to publish your base app to the Business Central before you download symbols. 

Also make sure that the idRange in your automated test project does not conflict with your base application, otherwise you will not be able to publish it in D365 Business Central. 

When you download symbols, Visual Studio Code will populate all the required symbol files as shown below: 

download-symbols

You will notice that your base app has been downloaded as symbols in alpackages folder. Also, you will see one new file called “Microsoft_Test_YourVersionNo.app”.  

You will need this file before you start writing AL Code for automated testing. Now you will have to import the test toolkit for your version of Business Central either from Development Environment or import it using PowerShell command prompt. 

Following is the PowerShell command that imports test toolkit into the application database. 

 Import-TestToolkitToNavContainer -containerName navserver 

You can also use -includeTestToolkit parameter while creating container in docker. If you use this parameter, you won’t have to import the test toolkit later manually. If you import the test toolkit later, you will have to generate the symbol reference first before downloading the symbol in visual studio code.  

Following is the command to generate the symbol reference: 

 finsql.exe Command=generatesymbolreference, Database=DatabaseNameHere, ServerName=ContaineNameHere\SQLEXPRESS 

Step 6: Code unit for automated testing 

Now everything is ready, let’s start creating a new code unit for automated testing. We will call it “Extended Dimension Test” and the id for the code unit will be 55201 

automated-testing

The code unit should of subtype test. So this will help identify the business central application to include this on test tool. 

If you look at the figure above, you will find the feature tag, this represents the name of the feature, application area, functional area or another aspect of the application. This list of tags must point to an area of your solution that is touched by the test. 

Step 7: Defining procedure for automated testing 

We’ve defined few library variables that are required while testing this application. This library comes with the test toolkit so, in most cases you will not have to worry. 

procedure for automated testing

So here you go, you will have to define your procedure as Test. This is the function type. If you forget to define the function type as Test, test tool will not include the function. 

It’s good idea to write what the test function does as shown in above figure. For each test tool it is also recommended to have GIVEN-WHEN-THEN tags so that these tags provide a framework for the specific test criteria. 

  • [GIVEN]: This tag is used for the lines of code that start setting up the different setups that are required before the application is tested. It’s more like creating setup if does not exists, creating documents and fill up all requirements before processing ahead. There can be multiple GIVEN tag. 
  • [WHEN]: This tag is used for the lines that describes the action under test. Example: Posting of Documents, Validations of something etc. There should be only one WHEN tag, if there is multiple you must separate the test into two or more tests. 
  • [THEN]: This tag is used for the lines that verifies the test results. You can add more than one THEN tag. 

Now let’s start the business central web client and see how it look when you use Test Tool:

 

 business central web client
Test Tool Dynamics 365 Business Central 

When you run the test, the result accomplished is a success. You do not have to worry about the document it generates when you test the application because all it does during testing gets roll backed. So, this is how you can start building automated testability in Dynamics 365 Business central.  

If you have any questions regarding this feature, call our friendly team on 01296 328689 or drop us an email at info@dogmagroup.co.ukOur team will be more than pleased to discuss these with you.