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

Setting up a test plan

Goal: Learn how to set up a test plan for an existing feature.

A test plan should list all possible tests that are needed to verify whether the application, or just a singular feature, is doing what it is expected to do. First of all, it should entail both the sunny scenarios, a.k.a. positive tests and often defined as user stories or use cases, and rainy scenarios, a.k.a. positive-negative tests, that is, tests that check that exceptions are handled. Next to that, it should clearly discriminate between tests that should be automated and those that do not have to. Regarding the first ones – those that need to be automated – it needs to be pointed out whether they check the business logic without accessing the UI, a.k.a. headless tests, and those that do need to verify UI specifics (UI tests). And finally, it has to prioritize tests, enabling the team to focus successfully on what needs to be tested beyond any doubt, and thus managing the risks...