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)
1
Section 1: Automated Testing – A General Overview
4
Section 2:Automated Testing in Microsoft Dynamics 365 Business Central
7
Section 3:Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central
12
Section 4:Integrating Automated Tests in Your Daily Development Practice
15
Section 5:Advanced Topics
19
Section 6:Appendix

Disabling failing tests

How about the almost two handfuls of remaining failing tests? These are standard tests that at this moment do not succeed in your environment. Whether it is because they are failing anyway or because they need some specific setup, it's not clear to me. In general, I will just disable them on the assumption that it's a relatively and absolutely small number of tests, and that the remaining successful ones give me a good enough health check of the code. Of course, if time allows, you might want to study them closer, but if the numbers are so low, please ask yourself if spending more time is worthwhile.

Disabling failing tests could be done manually using, for example, the test tool extension. A more repeatable solution, however, would be to use the DisabledTests.json feature provided by the Run-TestsInBcContainer cmdlet of the BcContainerHelper module, or one of the ALOps pipeline steps. To be able to create a valid DisabledTests.json file, you should...