Automated Test Development with AL

In the previous chapter, we saw how to debug AL extensions with Visual Studio Code.

In this chapter, we will have a look at how to write automated tests for an extension in AL. We need to do this in order to have a modern development life cycle, and it's mandatory if you want to publish your extensions on AppSource.

Using the demo extension that was developed in Chapter 5, Developing a Customized Solution for Dynamics 365 Business Central, we will cover the following topics:

• Designing tests using the Acceptance Test-Driven Development pattern
• Setting up a test extension
• The technique behind testing code
• Implementing test code

Test automation and testing design principles

Application testing is not rocket science. Neither is automated application testing. It's just another learnable skill. From a developer's perspective, however, you need a change of mindset to write code with a totally different purpose than you're used to do. It's common knowledge that developers should never test their own code, as they, consciously or unconsciously, know how to use the software and how to evade issues. They write code to make something work.

Testing, however, is not about how to make it; rather, it's about how to break it. But this knowledge applies to manual, exploratory testing, where tests are executed based on knowledge and experience, not to scripts. And automatic tests are scripts.

To code these scripts into automated tests, we'll need developers. And more often than not...

Designing tests with ATDD

In his book, Automated Testing in Microsoft Dynamics 365 Business Central, Luc van Vugt delves into how to design and implement your tests. Based on the so-called Acceptance Test-Driven Development (ATDD) methodology, he shows how to write your requirements like a test design using the ATDD pattern. This pattern introduces five tags:

• FEATURE: Defines what feature(s) the test or collection of test cases is testing.
• SCENARIO: Defines the scenario being tested for a single test.
• GIVEN: Defines what data setup is needed; a test case can have multiple GIVEN tags when the data setup is more complex.
• WHEN: Defines the action under test; each test case should have only one WHEN tag.
• THEN: Defines the result of the action, or more specifically, the verification of the result. If multiple results apply, multiple THEN tags will be needed.

The following is...

Preparing the environment

In order to start writing automated tests on your AL extension, you need to import Microsoft Test Framework into your Dynamics 365 Business Central environment. If you're working with Dynamics 365 Business Central on-premise (standalone installation), you can import it from the product DVD. If you are using a Docker-based development sandbox, you can import the Test Toolkit automatically with the navcontainerhelper module by adding the -includeTestToolkit switch parameter to the New-BcContainer cmdlet.

If you have an already-running Docker container with Dynamics 365 Business Central, you can import the Test Toolkit by using the following cmdlets:

Import-TestToolkitToBcContainer -containerName d365bcdev
Generate-SymbolsInNavContainer -containerName d365bcdev

The Test Toolkit Test Libraries consist of the following...

Setting up test development for extensions

If we take the most restrictive requirement for extensions (the requirement that Microsoft considers mandatory for approving your extension for release to AppSource), app and test code should be placed in separate extensions. As such, the test extension should have a dependency on the app extension.

This separation, however, might restrict the parallel development of the app and test code, since any change to an app extension results in its redeployment. This potentially also results in an update and redeployment of the test extension.

Before you realize it, you are continuously juggling your extensions, thereby reducing the productivity of the development team. The best course of action, while developing, is to have the app and test code placed in the same extension. Once it's ready, you can split up the code and create the...

Learning about the technique behind test code

Before we start coding tests, we need to learn a couple of things about the technique behind test code, the so-called testability framework.

Since NAV 2009 Service Pack 1, Microsoft has allowed the platform to let you build test suites by means of test functions in test codeunits. When executing a test codeunit, the platform will do the following:

• Run the OnRun trigger and each test function that resides in the test codeunit, from top to bottom
• Record the result of each test function

This is what Luc van Vugt calls the first pillar of the testability framework. Our first test example will implement this.

The second pillar allows you to create so-called positive–negative, or rainy-path, tests, in which we test the circumstances that led to failure. To achieve this, we use the AL asserterror keyword, which should...

Designing our test scenarios

As we've already mentioned, we will illustrate four of the five pillars of testability in a test example:

• Test codeunit and test function
• asserterror
• Test page
• UI handlers

We need to have designed each scenario to enable us to code a test efficiently and effectively. This is what we will do first in the following section.

In his book, Luc shows extensively how to get from requirements to an automated test, or as he calls it From customer wish to test automation.

Test codeunit and test function – test example 1

As test codeunits and test functions are the basis of test coding in AL, we could take any scenario as an example. But let's keep it simple and start with the basic...

Implementing our test scenarios

Given an ATDD scenario, we can effectively implement test code using the following four steps:

1. Create a test codeunit with a name based on the [FEATURE] tag.
2. Embed the requirement into a test function with a name based on the [SCENARIO] tag.
3. Write the test story based on the [GIVEN], [WHEN], and [THEN] tags.
4. Construct the real code.

Test codeunit and test function – test example 1

Let's perform this four-step recipe for our first test example with the following ATDD scenario:

• [FEATURE] Customer Category
• [SCENARIO #0001] Assign non-blocked customer category to customer
• [GIVEN] A non-blocked customer category
• [GIVEN] A customer
• [WHEN] Set customer category on customer
• [THEN] Customer...

Summary

In this chapter, we have discussed the basics of how to create automated tests in Dynamics 365 Business Central.

We utilized the ATDD test case pattern in order to design each test, and then used it as a base structure in our four-step recipe to create a test codeunit, embed the customer choice into a test, write a test story, and finally construct your real code. You should now be comfortable with writing tests for your extensions according to your business needs.

In the next chapter, we'll explore another important aspect to master when developing solutions for Dynamics 365 Business Central: source code management and DevOps practices.