You're reading from Automated Testing in Microsoft Dynamics 365 Business Central Efficiently automate test cases for faster development cycles with less time needed for manual testing

Product type Paperback

Published in Dec 2021

Publisher Packt

ISBN-13 9781801816427

Length 406 pages

Edition 2nd Edition

Tools

Dynamics 365

Concepts

Enterprise Resource Planning

Author (1):

Luc van Vugt

View More author details

Table of Contents (22) Chapters

Preface

1. Section 1: Automated Testing – A General Overview

2. Chapter 1: Introduction to Automated Testing FREE CHAPTER

3. Chapter 2: Test Automation and Test-Driven Development

4. Section 2:Automated Testing in Microsoft Dynamics 365 Business Central

5. Chapter 3: The Testability Framework

6. Chapter 4: The Test Tools, Standard Tests, and Standard Test Libraries

7. Section 3:Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central

8. Chapter 5: Test Plan and Test Design

9. Chapter 6: From Customer Wish to Test Automation – the Basics

10. Chapter 7: From Customer Wish to Test Automation – Next Level

11. Chapter 8: From Customer Wish to Test Automation – the TDD way

12. Section 4:Integrating Automated Tests in Your Daily Development Practice

13. Chapter 9: How to Integrate Test Automation in Daily Development Practice

14. Chapter 10: Getting Business Central Standard Tests Working on Your Code

15. Section 5:Advanced Topics

16. Chapter 11: How to Construct Complex Scenarios

17. Chapter 12: Writing Testable Code

18. Chapter 13: Testing Incoming and Outgoing Calls

19. Section 6:Appendix

20. Other Books You May Enjoy

Appendix: Getting Up and Running with Business Central, VS Code, and the GitHub Project

Test example 7 – how to refactor your code

From a TDD perspective, the previous six test examples fully neglected a very essential part: the refactoring of the code, or more accurately, one of the two rules that make TDD: Rule 2 Eliminate duplication.

As I hope you will experience here, refactoring is not rocket science but a discipline, as I tend to call it. Refactoring is not a goal on its own, but a means to exercise this second rule of TDD, with the valuable resulting effects of getting reusable, readable, and minimalistic code.

Contrary to what many of us have been taught when becoming a developer, though, with TDD we do not design reusable, readable, and minimalistic code upfront. No, when performed with common coding sense, rule 2 leads you there. As you might recall from Chapter 2, Test Automation and Test-Driven Development, with TDD your first gear is taking small steps to be effective and efficient. Meaning that you don't do more than required for that...