Book Image

Automated Testing in Microsoft Dynamics 365 Business Central - Second Edition

Book Image

Automated Testing in Microsoft Dynamics 365 Business Central - Second Edition

Overview of this book

Dynamics 365 Business Central is a cloud-based SaaS ERP proposition from Microsoft. With development practices becoming more formal, implementing changes or new features is not as simple as it used to be back when Dynamics 365 Business Central was called Navigator, Navision Financials, or Microsoft Business Solutions-Navision, and the call for test automation is increasing. This book will show you how to leverage the testing tools available in Dynamics 365 Business Central to perform automated testing. Starting with a quick introduction to automated testing and test-driven development (TDD), you'll get an overview of test automation in Dynamics 365 Business Central. You'll then learn how to design and build automated tests and explore methods to progress from requirements to application and testing code. Next, you'll find out how you can incorporate your own as well as Microsoft tests into your development practice. With the addition of three new chapters, this second edition covers in detail how to construct complex scenarios, write testable code, and test processes with incoming and outgoing calls. By the end of this book, you'll be able to write your own automated tests for Microsoft Business Central.
Table of Contents (22 chapters)
Section 1: Automated Testing – A General Overview
Section 2:Automated Testing in Microsoft Dynamics 365 Business Central
Section 3:Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central
Section 4:Integrating Automated Tests in Your Daily Development Practice
Section 5:Advanced Topics
Section 6:Appendix

What is automated testing?

We discussed why you might want to automate your tests and when to do this, and more specifically, where to start. But we didn't give any thought to what automated testing is. So, let's do that before we conclude this chapter.

With automated testing, we address the automation of application tests, that is, scripting manual application tests that check the validity of features. In our case, these are the features that reside in Dynamics 365 Business Central. You might have noticed that we have been using somewhat different terms for it:

  • Test automation
  • Automated tests
  • Automated testing

These all mean the same thing!!!

On one hand, automated testing is replacing manual, often exploratory testing. It's replacing those manual tests that are repeatable and automatable, and often no fun (anymore) to execute.

On the other hand, they are complementary. Manual testing will still contribute to raising the quality of a feature, making use of creative and experienced human minds able to find holes in the current test design. Automated testing might also include so-called unit tests. These are tests that verify the working of atomic units that altogether make up a feature. Typically, these units would be single, global AL functions – units that would never be tested manually. Ultimately, both manual and automated tests serve the same goal: to verify that the object under test meets the requirements and doesn't do anything outside of the requirements.


(1) What is exploratory testing? Check out the following link for more information:

(2) More on unit and functional tests can be found at the following link: We will also elaborate more on unit tests in this book.

Some more notes on automated tests

Before we head off to the next chapter, I would like to add a couple of notes on automated tests that haven't been touched on so far.

Automated tests are code too

There is no sense in denying: automated tests are also code. It takes time to design, implement, and maintain them. Like application code, any line of test code has a probability of containing a bug. The challenge is to keep this to a bare minimum. You can achieve this by:

  • Making the test design a part of the requirements and requirements review
  • Reviewing your test code like you would want to review your application code
  • Making sure that tests always end with an adequate number of verifications

And, please, like any source, put your tests under source code management. They're a part of your product. Make sure to reserve time for this in your planning.

Automated tests need maintenance

Over time, your application changes and therefore the tests that go with it, be it manual or automated tests. Any change in the application, if well covered by test scenarios, will reflect in a number of failing tests as these no longer fit. Even a simple change in the order of the application code can lead to one or more tests falling over.

Testing vs. checking

One of the reviewers of this book, Xavi Ametller Serrat, pointed out the difference between testing and checking. With testing, we investigate and learn, while checking is about confirming and verifying. The first is typically a human exercise, while the second is what we can automate. Given this insight, automated testing should rather be called automated checking. In this book, however, the first term will be used as this links more to a common notice.


An interesting read on testing versus checking can be found here: