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
1
Section 1: Automated Testing - A General Overview
3
Section 2: Automated Testing in Microsoft Dynamics 365 Business Central
6
Section 3: Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central
11
Section 4: Integrating Automated Tests in Your Daily Development Practice

TDD, a short description

The shortest possible description of TDD is actually the term itself. It is self-containing. It is describing that, by using this as your methodology for your software application development, the development will be driven by tests. Tests need to be defined to drive the writing of your application code, and in this way, your tests are directly derived from the requirements. This is an often uttered one-liner to describe TDD in a nutshell:

"No tests, no code."

The ultimate consequence of this is that you will never build application code that does not have tests to it. And, as the tests are one-to-one related to the requirements, your application code should not have any undocumented features.

But this description is actually not the basic definition of TDD. TDD is defined only by the following two rules, and everything else is deduced from that...