Book Image

.Automated Testing in Microsoft Dynamics 365 Business Central

By : Luc van Vugt
Book Image

.Automated Testing in Microsoft Dynamics 365 Business Central

By: Luc van Vugt

Overview of this book

Dynamics 365 Business Central is the new cloud-based SaaS ERP proposition from Microsoft. It’s not as simple as it used to be way back when it was called Navigator, Navision Financials, or Microsoft Business Solutions-Navision. Our development practices are becoming more formal, and with this, the call for test automation is pressing on us. This book will teach you to leverage testing tools available with Dynamics 365 Business Central to perform automated testing. We’ll begin with a quick introduction to automated testing, followed by an overview of test automation in Dynamics 365 Business Central. Then you’ll learn to design and build automated tests and we’ll go through some efficient methods to get from requirements to application and testing code. Lastly, you’ll learn to incorporate your own and Microsoft tests into your daily development practice. By the end of the book, you’ll be able to write your own automated tests for Dynamics 365 Business Central.
Table of Contents (17 chapters)
Free Chapter
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

When to use automated testing

Those are enough arguments to convince you why you would want to use automated tests, I guess. But how about when to use them? Ideally, this would be whenever code is changed to show that this functionality, already having been tested, is still working as it should, to show that recent modifications do not compromise the existing application.

This sounds logical, but what does this mean when you have no automated tests in place? How do you go about start creating your first ones? Basically, I would advise you to use the two following criteria:

  • What code change will give the highest return on investment when creating automated tests?
  • For what code change will your test automation creation improve your test coding skills the most?

Using these two criteria, the following kind of code changes are typical candidates for your first efforts:

  • After go-live bug fixing
  • Buggy code
  • Frequently modified code
  • Business-critical code being changed
  • Refactoring of existing code
  • New feature development
  • Microsoft updates

After go-live bug fixing

An after go-live bug reveals an omission in the initial test efforts that can often be traced back to a flaw in the requirements. Frequently, it has a restricted scope, and, not the least important, a clear reproduction scenario. And by all means, such a bug should be prevented from ever showing its ugly face.

Buggy code

You have this feature that keeps on bugging you and your customers. Bugs keep on popping up in this code and it never seems to stop. The most elementary thing you should start with is the after go-live bug fixing approach as previously discussed. But, even more importantly, use this code to create a full test suite for the first time.

Bugs are a particularly useful starting point, because they usually provide the following:
  • A defined expectation
  • Steps to reproduce the scenario
  • A clear definition of how the code fails

Frequently modified code

One of the basic rules of good code governance is that code should only be changed when it is going to be tested. So, if code is modified frequently, the consequence is that it will also be tested frequently. Automating these tests will give a good return on investment for sure.

Business-critical code being changed

Thorough testing should always be the case, but, given circumstances, it is unfortunately not always doable. Testing changes made to business-critical code, however, should always be exhaustive. You can simply not afford any failure on them. Make it a point of honor to find even the two to five percent of bugs that statistics tell us are always there!

Refactoring of existing code

Refactoring code can be nerve-racking. Removing, rewriting, and reshuffling. How do you know it is still doing the job it used to? Does it not break anything else? It certainly needs to be tested. But, when manually done, it is often executed after the whole refactoring is ready. That might be already too late, as too many pieces got broken. Grant yourself peace of mind and start, before any refactoring, by getting an automated test suite in place for this code to prove its validity. With every refactor step you take, run the damn suite. And again. This way, refactoring becomes fun.

New feature development

Starting from scratch, both on test and app code, will be an irrefutable experience. For some, this might be the ultimate way to go. For others, this is a bridge too far, in which case, all previous candidates are probably better ones. In Section 3, Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central, we will take this approach and show you the value of writing test code alongside app code.

Microsoft updates

Incorporating any update from Microsoft, be it on-premises or in the cloud, your features must be (re)tested to prove they're still functioning like before. In case you do not have automated tests in place, begin creating them. Do this based on the analysis of the various changes and the risks they might entail of introducing errors.