Automated Testing in Microsoft Dynamics 365 Business Central E-Book

Luc van Vugt

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 436

Veröffentlichungsjahr: 2021

Beschreibung

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.

Leseprobe

Automated Testing in Microsoft Dynamics 365 Business Central

Second Edition

Efficiently automate test cases for faster development cycles with less time needed for manual testing

Luc van Vugt

BIRMINGHAM—MUMBAI

Automated Testing in Microsoft Dynamics 365 Business Central

Second Edition

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Alok Dhuri

Publishing Product Manager: Richa Tripathi

Senior Editor: Ruvika Rao

Content Development Editors: Nithya Sadanandan and Ananya Endow

Technical Editor: Pradeep Sahu

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Subalakshmi Govindhan

Production Designer: Sinhayna Bais

Marketing Coordinator: Sonakshi Bubbar

First published: April 2019

Second edition: December 2021

Production reference: 1081221

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80181-642-7

www.packt.com

To all that keep me growing as a human being; not in the least my wife, Saskia, our three great kids, Cyriel, Elvira, and Micha, my family and friends, and all the students I had the chance to teach and meet over the years.

– Luc van Vugt

Contributors

About the author

In 1999, Luc van Vugt stepped into the Dynamics 365 Business Central world, training hundreds of developers. After Microsoft acquired Navision, he joined Microsoft's Dynamics localization team GDL as a tester, UA specialist, and project lead. For 6 years, he was closely involved with all successive releases. Since he left Microsoft, he has become an active community member by means of his blog. He is a co-founder of the Dutch Dynamics Community and a speaker at conferences. For all his community work, Luc has been awarded MS MVP since 2011. In 2014, he co-founded NAV Skills, supporting Dynamics 365 Business Central, at that time still called Dynamics NAV, pros around the globe with, among other things, webinars until 2019. He has continued ever since to organize webinars under the flag of Areopa webinars. In 2012, Luc started fluxxus.nl, doing miscellaneous projects, including Dynamics 365 Business Central development courses and workshops on design patterns, and automated testing. Luc is one of the main driving forces on test automation in the Dynamics 365 Business Central community.

There are many people I am thankful to, for helping me gain the knowledge that I am sharing with you – but a couple to mention explicitly here:

The interview volunteers where the project of this second edition started with: Tin, Xavi, Maarten, Gert, Krzysztof, Jeremy, Guido, and Olaf.

Xavi Ametller Serrat, Maarten Gerritsen, and Daniel Rimmelzwaan for their invaluable reviews with great suggestions that gave the book more than I could have on my own.

The Packt team, who did a great job, surpassing my initial expectations by far.

About the reviewers

Daniel Rimmelzwaan was born and raised in the Netherlands and moved to the USA at the end of 1999 to be with his American wife in the beautiful mountains of Northern Arizona. Over the past two decades, Daniel has worked in just about every role around implementing NAV and now Business Central. He currently owns his own business (risplus.com) doing business analysis, architecture and design, and development. He is enjoying his career more than ever.

Ever since he started working with Business Central, Daniel has contributed to its online communities. For those contributions, Daniel received his first of seventeen consecutive Microsoft MVP awards in July 2005. Follow Daniel's blog at http://thedenster.com/.

Maarten Gerritsen has over 20 years of experience with Business Central and its predecessors, NAV/Navision. With Business Central, he can do what he loves most: creating solutions for the SMB market. He has a strong focus on process analysis and solution architecture. He worked for implementation partners and has been self-employed since 2007 (www.intelligo.nl).

Finally, when starting to develop for AppSource in 2019, he was forced to do something with automated testing. This got him hooked and he got passionate about the ATDD methodology, and it changed the way he creates solutions with Business Central.

Maarten lives in the Netherlands with his wife and two children. They teach him the most valuable lessons in life every day.

Xavier Ametller has been working in software development since 2003. Around 2009, he was a tester in what was called Microsoft Dynamics NAV, where he was lucky to meet Luc and discovered what now is Business Central.

When he left Microsoft, Xavi moved away from the BC world so he's not an expert on the topic. On the other hand, Xavi has participated in developing software in multiple roles and contexts during his career, so he tried to bring a view from the outside world while reviewing this book.

Xavi has a blog at https://www.myowncommonsense.com/ where he shares rants on software development. As a side quest to his job, he offers training and consultancy on development-related topics.

Xavi and his family live happily in Catalonia, Spain.

Table of Contents

Preface

Section 1: Automated Testing – A General Overview

Chapter 1: Introduction to Automated Testing

Why automated testing?

Why not?

Why yes?

Some more arguments

Silver bullet?

When to use automated testing?

After go-live bug fixing

Buggy code

Frequently modified code

Business-critical code being changed

Refactoring existing code

New feature development

Microsoft updates

What is automated testing?

Some more notes on automated tests

Summary

Chapter 2: Test Automation and Test-Driven Development

TA versus TDD

What is TDD?

Only two rules to the game

TDD – the red-green-refactor mantra

TDD – taking small steps

TDD – the benefits

TDD and Microsoft Dynamics 365 Business Central

Is TDD in Business Central possible?

Don't know how to start?

TDD in Business Central – by example

TDD – all the way?

TDD – inside-out or outside-in

Summary

Further reading

Section 2:Automated Testing in Microsoft Dynamics 365 Business Central

Chapter 3: The Testability Framework

Technical requirements

The five pillars of the testability framework

Pillar 1 – Test codeunits and test functions

Pillar 2 – The asserterror keyword

Pillar 3 – Handler functions

Pillar 4 – Test runner and test isolation

Pillar 5 – Test pages

Summary

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

Technical requirements

Test Tools

Adding tests to a test suite

Running the tests

Standard tests

Base Application tests

Categorization by FEATURE

Standard libraries

Finding useful standard helper functions

Some generic and very useful standard libraries

Summary

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

Chapter 5: Test Plan and Test Design

No plan, no test

Setting up a test plan

Break down your application or feature

Test case design patterns

Four-phase testing

Acceptance Test-Driven Development

A note on test verification

Applying test case design patterns successfully

Test data setup design patterns

Test fixture, data agnostics, and prebuilt fixture

Test fixture and test isolation

Shared fixture implementation

Fresh fixture implementation

Applying test data setup design patterns successfully

Using customer wish as test plan

And what about unit and functional tests?

Test case design pattern and unit tests

Functional testing versus integration testing

Summary

Further reading

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

Technical requirements

From customer wish to test automation

Data model

Business logic

Converting our customer wish into a test plan and test design

Test example 1 – a first headless test

Customer wish

Application code

Test code

Test execution

Test example 2 – a first positive-negative test

Test code steps

Create a test codeunit

Test execution

Test example 3 – a first UI test

Customer wish

Test code

Test execution

Headless versus UI

Summary

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

Technical requirements

Sales documents, customer template, and warehouse shipment

Test example 4 – how to set up a shared fixture

Customer wish

Application code

Test Code

Test execution

Test example 5 – how to parameterize tests

Customer wish

Application code

Test code

Test execution

A missing scenario?

Test example 6 – how to hand over data to UI handlers

Customer wish

Test code

Test execution

Summary

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

Technical requirements

TDD and our test examples

Test example 7 – how to refactor your code

Smell of duplication 1

Smell of duplication 2

Some more duplications?

Refactoring application code, not covered by tests yet

Test example 8 – how to test a report

Customer wish

Step 1 – Take a test from the test list and write the test code

Step 2 – Compile test code yielding red as application code is not yet there

Step 3 – Add just enough application code

Step 4 – Run test seeing it probably fail

Step 3 bis – Add just enough application code

Step 4 bis – Run test seeing it probably fail

Step 5 – Adjust the application code just enough to make it pass

Step 6 – Refactor your code and rerun the test to prove all code is still well

Test the test

Test example 9 – how to test with permissions

Step 1 – Take a test from the test list and write the test code

Step 2 – Compile test code yielding red as application code is not yet there, and Step 3 – Add just enough application code

Step 4 – Run the test seeing it probably fail

Step 5 – Adjust application code just enough to make it pass, and Step 6 – Refactor your code and rerun the test to prove all code is still well

Step 7 – Move to the next test on the list and repeat from Step 1

Continue the red-green-refactor mantra

Some notes on testing permissions and the version of Business Central

Summary

Section 4:Integrating Automated Tests in Your Daily Development Practice

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

Technical requirements

Casting the customer wish into ATDD scenarios

ATDD.TestScriptor

Learning and improving by taking small steps

Making the test tool, and some more, your friend

Extending the test tool

AL Test Runner

Code Coverage

Maintaining your test code

Organizing your extensions

Integrating with the daily build system

Using pipelines

Or not using pipelines

Summary

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

Technical requirements

Why use the standard tests?

Executing standard tests against your code

Executing Tests-VAT

What does this tell us?

Only selecting tests from Tests-VAT

Running tests using pipelines

Fixing failing standard tests

Attacking the error

Fixing the error

Running the failing tests again

Disabling failing tests

Syntax of DisabledTests.json

It's all about data

Executing and fixing Tests-Fixed Asset

Running tests using pipelines

Is it all really about data?

Summary

Section 5:Advanced Topics

Chapter 11: How to Construct Complex Scenarios

Technical requirements

What makes a scenario complex?

Data setup

Verification

End-to-end code execution path

Dependencies on other systems

Composing complex scenarios

Finding common ground – steps 1, 2, 3, and 4

Deconstructing your scenario – steps 1, 2, 3, and 4

Using flowcharts – steps 1 and 3

Using Code Coverage – steps 1 and 3

Using standard helper functions – steps 5, 6, and 7

Creating reusable parts

Test example 10 – how to construct an extensive scenario

Customer wish

Application code

Test code

Test execution

Summary

Chapter 12: Writing Testable Code

Technical requirements

What is testable code?

How to make your code testable?

Coding techniques

Some notes on refactoring your code so it is testable

Test example 11 – how to unit test event subscribers' logic

Customer wish

Application code

Test code

Test execution

Summary

Further reading

Chapter 13: Testing Incoming and Outgoing Calls

Technical requirements

Testing incoming calls

Technical challenges

Examples of standard API tests

Testing outgoing calls

Test Doubles

Replacing a server with a test double – dependency injection

Some more notes on mock and mocking

Examples of standard tests with test doubles replacing external components

Test example 12 – testing incoming calls: Lookup Value API

Application code

Test scenarios

Test Code – [SCENARIO #0200] Get lookup value

Test Code – [SCENARIO #0202] Modify lookup value

Test preparation

Test execution

Test example 13 – VAT Registration No. validation

Application code

Test code

Test execution

Summary

Section 6:Appendix

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

Setting up your Business Central environment

Setting up Business Central from a product DVD

Setting up Business Central in a container

The GitHub repository

Structure of the GitHub repository

Chapter 02

Chapter 03

Excel Sheets

Chapter 06 (LookupValue Extension)

Chapter 07 (LookupValue Extension)

Chapter 08 (LookupValue Extension)

Chapter 09 (LookupValue Extension)

Chapter 10 (LookupValue Extension)

Chapter 11 (LookupValue Extension)

Chapter 12 (LookupValue Extension)

Chapter 13 (LookupValue Extension)

Scripts

Chapter 13 (VAT Registration No. Validation)

LookupValue Extension

Graphics

Setting up VS Code

VS Code project

Notes on the AL code

Prefix or suffix

Word wrap

Why subscribe?

Other Books You May Enjoy

Preface

With recent changes, not least the evolution of Microsoft Dynamics NAV into Dynamics 365 Business Central, your development practices need to become more formal. Your success will depend, more than ever before, on your ability to determine the quality of your work more quickly and more consistently. Traditional, that is, manual testing, practices will not be sufficient anymore. So, you need to learn automated testing and how to efficiently include this in your daily work. In this book, you will learn how it will enhance your work, functionally and technically, and hopefully learn to love it.

Who this book is for

This book is for developers, development managers, testers, functional consultants, and power users working with Microsoft Dynamics 365 Business Central. Being a book on automated testing techniques, it caters to both the functional and technical aspects of Business Central development.

The reader is assumed to have a general understanding of Dynamics 365 Business Central as an application and how this application can be extended. Even though some sections will be dedicated to the coding of automated tests, it's not mandatory to be able to write code for Dynamics 365 Business Central. Overall, it sure gives the reader an advantage to be able to think as a tester.

What this book covers

Chapter 1, Introduction to Automated Testing, introduces you to automated testing: why you would want to use it, what it exactly entails, and when you should use it.

Chapter 2, Test Automation and Test-Driven Development, gives a short description of what Test-Driven Development (TDD) is and points out parts that can be of value to your daily development practices too.

Chapter 3, The Testability Framework, elaborates on how Microsoft Dynamics 365 Business Central enables you to run automated tests, and what this so-called Testability Framework actually is by describing its five pillars.

Chapter 4, The Test Tools, Standard Tests, and Standard Test Libraries, introduces the testing tool that resides in Dynamics 365 Business Central and allows you to run tests. Alongside that, we will discuss the standard tests and test libraries that Microsoft provides with Dynamics 365 Business Central.

Chapter 5, Test Plan and Test Design, discusses a couple of concepts and design patterns that allow you to conceive your tests more effectively and efficiently.

Chapter 6, From Customer Wish to Test Automation – the Basics, teaches you – and allows you to practice, based on a business case – how to get from a customer's requirement to the implementation of automated tests. In this chapter, you will make use of standard test libraries and techniques discussed in the previous chapters. The examples in this chapter will teach you the basics of headless and UI testing, and how to handle a positive-negative test.

Chapter 7, From Customer Wish to Test Automation – Next Level, continues the business case from Chapter 6, From Customer Wish to Test Automation – the Basics, and introduces some more advanced techniques: how to make use of shared fixtures, how to parameterize tests, and how to handle UI elements and hand over variables to these so-called UI handlers.

Chapter 8, From Customer Wish to Test Automation – the TDD Way, elaborates on how you can get your (test) coding done the Test-Driven Development way, putting test first all the way. Meanwhile you'll get introduced to two more examples and continue with the same business case from the previous two chapters: how to go about testing a report and how to set up permission testing.

Chapter 9, How to Integrate Test Automation in Daily Development Practice, discusses a number of best practices that might turn out to be beneficial for you and your team in getting test automation up and running in your day-to-day work.

Chapter 10, Getting Business Central Standard Tests Working on Your Code, discusses why you would want to use the standard test collateral Microsoft provides with Dynamics 365 Business Central, and how to fix errors when standard tests fail due to your extension of the standard application.

Chapter 11, How to Construct Complex Scenarios, shows you how to go about getting automated tests in place for complex scenarios, how to create reusable parts for them, and how to make use of already existing helper functions in the Microsoft test libraries.

Chapter 12, Writing Testable Code, introduces the concept of testable code: how to get your application code better suited to be tested with automated tests.

Chapter 13, Testing Incoming and Outgoing Calls, discusses how to test features that communicate with external systems, either being called from or calling on the outside world.

Appendix, Getting Up and Running with Business Central, VS Code, and the GitHub Project, pays attention to VS Code and AL development, and the code examples to be found in the repository on GitHub.

To get the most out of this book

This book is an introduction to test automation for Dynamics 365 Business Central. On one hand, various concepts and terminology are discussed, and on the other hand, we will also practice them by coding tests. To get the most out of this book, you might want to practice what is preached by implementing the code examples discussed. As this book, however, does not cover how to program for Business Central, you might first want to read the tips given in Appendix, Getting Up and Running with Business Central, VS Code, and the GitHub Project.

If your learning style is to start by finding out the principles, terminology, and concepts, start reading Chapter 1, and move slowly into the more practical Section 3, Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central. If your style is more learning by doing, you could dare to take a deep dive into Chapter 6, Chapter 7, and Chapter 8 straight away, and read the various backgrounds later or while working through the chapters.

Note

We advise you to type the code yourself or access the code from the book's GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition. If there's an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Get the color images

You can find the color images of the screenshots and diagrams used in this book in the GitHub repository: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Graphics.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "The only step to be taken is to add the following code to the relevant Initialize function."

A block of code is set as follows:

fields

{

field(1; Code; Code[10]){}

field(2; Description; Text[50]){}

}

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold and in specific coloring with respect to certain tags:

[FEATURE] LookupValue Customer

[SCENARIO #0001] Assign lookup value to customer

[GIVEN] A lookup value

[GIVEN] A customer

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: "Select System info from the Administration panel."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read Automated Testing in Microsoft Dynamics 365 Business Central, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.

Section 1: Automated Testing – A General Overview

In this section, you will be introduced to automated testing. We will discuss why you would want to use it, what it exactly entails, and when you should use it.

This section contains the following chapters:

Chapter 1, Introduction to Automated TestingChapter 2, Test Automation and Test-Driven Development

Chapter 1: Introduction to Automated Testing

A couple of years ago, I finally got to write this book on application test automation – one I had wanted to write for a long time already, as automated testing doesn't appear to be a love-at-first-sight topic for many. And, like testing in general, in many implementations, it tends to be subordinate to requirements specifications and application coding, be it a project or a product. And who really loves testing? It is not typically what the average developer gets enthusiastic about. Even functional consultants do not easily step up, for example, when raising this question during many of my workshops on automated testing.

So, when I started writing this book, inevitably, I did pose the question to myself: do I love testing? And I answered it with a yes. A big YES. This subsequently led to additional questions, such as: What makes me love testing? Did I always love testing? Why do I love it while the rest of the world seems not to? Questions with answers that made me go around the world evangelizing test automation, stubbornly sharing my findings, and pushing Microsoft to improve their tests to make them better and reusable. And all because I reckon that it is fun – BIG fun!

Having been an application tester in the former Dynamics NAV Global Development Localization (GDL) team at Microsoft, I surely got exposed to the testing virus. You could say that I had to learn to do the testing job, as I was paid for it. But it also suited me well, with me apparently having this specific DNA kind of a thing that makes testers what testers are. Having pride in breaking the thing and loving to prove its robustness (hopefully) at the same time. And, not in the least, daring to break it, running the risk that your developers will no longer like you.

One afternoon at Microsoft, my developer team member walked into our office and stopped next to my desk. Him being very tall and me sitting, I had to turn my head up to look at him.

"What's up?" I asked.

"Don't you like me anymore?" he responded.

Me: What?

Him: "Don't you like me anymore?"

Me: "Nope, still like you. Why?"

Him: "You rejected my code; don't you like me anymore?"

Me: "Dude, I still like you, but concerning your code, my tests show it somehow useless."

Testing is not rocket science, nor is automated testing. It's just another learnable skill. From a developer's perspective, however, it requires a change of mindset to write code with a totally different purpose than you are used to. And we all know that change is often not the easiest thing to achieve. Because of this, it's not unusual for attendees at my workshops to get to a certain level of frustration.

Application testing is a mindset, and it needs a big dose of discipline too – the discipline to do what needs to be done: to verify that the feature was built right; to verify that the feature under test meets the requirements – and the discipline when bugs are reported and fixed to execute the whole test run again and again with any new bug, to ensure that the verification is complete.

I tend to see myself as a disciplined professional. I have been quite a disciplined tester, with a high rate of bug reporting. But did I always love testing? You know, in those days, all our tests were executed manually, and with each bug I found, my discipline was challenged in some way. Imagine my mind running when executing the fifth test run after another bug fix. It's 4:00 P.M. and I am almost done, and the feature under test has to be delivered today. At breakfast, I promised my wife that I would be home on time, for whatever reason. Let's pick a random one: our wedding anniversary. So, me being a disciplined tester, my promise to be home on time, 4:00 P.M., and … I … hit … another … bug. Knowing that fixing it and rerunning the tests would take at least a couple of hours; how do you think my mind is running? Right: binary.

I had two options:

Reporting the bug would keep me at work and make my wife highly disappointed, to say the least.Not reporting the bug would get me home on time and save me trouble at home.

Had automated tests been in place, the choice would have been quite simple: the first option, resulting in no hassle at home and no hassle at work. Welcome to my world. Welcome to test automation!

In this chapter, we will discuss the following topics:

Why automated testing?When to use automated testing?What is automated testing?

Note

If you prefer to read the what first, you might first want to jump to What is automated testing?

Why automated testing?

Plainly said: it all boils down to saving you a lot of hassle. There are no emotions or time-intensive execution that will keep you from (re)running tests. It's just a matter of pushing the button and getting the tests carried out. This is easily reproducible. Each time you push the button, the test will be executed exactly the same. It is fast to execute, as automated tests are "light-years" faster than any of us could do, and objective: a test fails or succeeds, and this will be part of the overall reporting. No human emotions that could hide it away.

If it was as straightforward as that, then why haven't we been doing this in the Dynamics 365 Business Central world all these years? You probably can come up with a relevant number of arguments yourself. Of which the most prominent might be we do not have time for that. Or maybe: who's going to pay for that?

Why not?

Before elaborating on any arguments, pros or cons, let me create a more complete why not? list. Let's call it the whys of non-automated testing:

Costs are too high and will make us uncompetitive.We are not used to doing it this way and our sales and management team don't see the benefits and cannot be "convinced."Dynamics 365 Business Central platform does not enable it.Customers do the testing, so why should we bother?Who's going to write the test code? We already have a hard time finding people.Our everyday business does not leave room to add a new discipline.There are too many different projects to allow for test automation.Microsoft has tests automated, and still, Dynamics 365 Business Central is not bug-free.

Why yes?

Dynamics 365 Business Central is not as simple as it used to be way back when it was called Navigator, Navision Financials, or Microsoft Business Solutions – Navision. And the world around us isn't as one-fold either. Our development practices are becoming more formal, and, with this, the call for testing automation is pressing on us for almost the same reasons as the whys of non-automated testing:

Drive testing upstream and save costs.Dynamics 365 Business Central platform enables test automation.Relying on customers to do the testing isn't a great idea.Having a hard time finding people – start automating your tests.Test automation will free up time for everyday business.Keep on handling different projects because of test automation.

Let's check each of these aspects separately.

Drive testing upstream and save costs

Regarding costs, I tend to say that a Dynamics 365 Business Central project goes 25% over budget on average, mainly due to bug fixing after go-live. Quite a number of attendees of my workshops, however, have tended to correct me, saying that this is on the low side. Whatever percentage is the case, the math is quite simple. If you're spending 25% extra at the end of the line, why not push it upstream and spend it during the development phase on automated testing, and meanwhile build up reusable collateral? Even more, this also ends up being a powerful multiplier as any defect solved earlier in the project chain, or what we also call upstream, is a factor cheaper than being solved later in the project, that is, downstream.

If my memory is not failing me, this factor could be as large as 1,000. During my time at Microsoft in the 2000s, research was performed on the cost of catching a bug in the different stages of developing a major release of a product. Catching a bug after the release was found to be approximately 1,000 times costlier than when catching the bug already at requirement specification.

Translating this to the world of an independent software vendor (ISV), this factor might roughly be 10 times lower. Meaning that the cost of catching a bug all the way downstream would be 100 times higher than all the way upstream. In the case of a value-added reseller (VAR) doing one-off projects, this factor probably is 100 times lower. So, whatever the factors would be, any spending upstream is more cost-effective than downstream, be it more formalized testing, better app coding, code inspection, or specifying more detailed requirements.

Note

A while ago, I wrote a joint blog post that also discussed this. You might want to read it:

https://www.fluxxus.nl/index.php/BC/from-a-testing-mindset-to-a-quality-assurance-based-mindset.

Dynamics 365 Business Central platform enables test automation

In all honesty, this is a no-brainer as this is the topic of this book. But it is worthwhile realizing that the testability framework inside the platform has been there ever since version 2009 SP1, released in the summer of 2009. So, for over 10 years, the platform has enabled us to build automated tests. Does it sound strange if I say that we have been sleeping for a long time? Sticking to old habits? At least most of us.

Relying on customers to do the testing isn't a great idea

I agree that customers might know their features the best, and as such, they are the presumable testers. But can you rely 100% that testing isn't being squeezed between deadlines of implementation, and, in addition, between deadlines of their daily work? And still, in what way does their testing contribute to a more effective test effort in the future? How structured and reproducible will it be?

Posing these questions answers them already. It isn't a great idea, in general, to rely on customer testing if you want to improve your development practices. Having said that, this doesn't mean that customers should not be included; by all means, incorporate them into setting up your automated tests. We will elaborate on that more later.

Having a hard time finding people – start automating your tests

At this very moment, all implementation partners in the Dynamics world are having a hard time finding people to add to their teams in order to get the work done. Note that I deliberately didn't use the adjective right in that sentence. We all are facing this challenge. And, even if human resources were abundant, practices show that, with a growing business in either volume or size, the number of resources used does not grow proportionally.

Consequently, we must all invest in changing our daily practices, which very often leads to automation, using, for example, PowerShell to automate administrative tasks and RapidStart methodology for configuring new companies. Likewise, writing automated tests to make your test efforts easier and faster. Indeed, it needs a certain investment to get it up and running, but it will save you time in the end.

Test automation will free up time for everyday business

Similar to getting the job done with proportionally fewer resources, test automation will eventually be of help in freeing up time for everyday business. This comes with an initial price but will pay off in due time.

Note

A logical question posed when I touch on the topic of spending time when introducing test automation concerns the ratio of time spent on application and test coding. Typically, in the Microsoft Dynamics 365 Business Central team, this is a 1:1 ratio. Meaning that, for each hour of application coding, there is 1 hour of test coding.

Keep on handling different projects because of test automation

Traditional Dynamics 365 Business Central implementation partners typically have their hands full of customers with a one-off solution. And, due to this, they have dedicated teams or consultants taking care of these installations; testing is handled in close cooperation with the end user, with every test run putting a significant load on those involved. Imagine what it would mean to have automated test collateral in place – how you would be able to keep on servicing those one-off projects as your business expands.

On any major development platform, such as Visual Studio, it has been a common practice for a long time already that applications are delivered with test automation in place. Note that more and more customers are aware of these practices. And, more and more will ask you why you are not providing automated tests for their solution.

Each existing project is a threshold to take having a lot of functionality and no automated tests. In a lot of cases, a major part of the features used is standard Dynamics 365 Business Central functionality, and, for these, Microsoft has made their own tests available since version 11, that is, Dynamics NAV 2016. Altogether, over 33,000 tests have been made available for the latest version of Business Central. This is a humongous number, of which you might take advantage and make a relatively quick start on. We will discuss these tests and how you could get them running on any solution later.

Some more arguments

Still not convinced why you would/should/could start using test automation? Do you need more arguments to sell it inside your company and to your customers?

Here are some more arguments:

Nobody loves testing.Reduced risks and greater satisfaction.Once the learning curve is over, it will often be quicker than manual testing.Leveraged development practice.Shorter update cycles and the AppSource paradigm.Test automation is required(?).

Nobody loves testing

Well, almost nobody. And, surely, when testing means rerunning and rerunning today, tomorrow, and next year, it tends to become a nuisance, which deteriorates the testing discipline. Automate tasks that bore people and free up time for more relevant testing where manual work makes a difference.

Reduced risks and greater satisfaction

Having automated test collateral enables you to have quicker insight than ever before into the state of the code. And, at the same time, when building up this collection, the regression of bugs and the insertion of new ones will be much lower than ever before. This all leads to reduced risks and greater customer satisfaction, and your management will love this.

Once the learning curve is over, it will often be quicker than manual testing

Learning this new skill of automating your tests will take a while, no doubt about that. But, once mastered, conceiving and creating them will often be much quicker than doing the thing manually as tests often are variations of each other. Copying and pasting with code is ... well ... can you do such a thing with manual testing? Not to mention to choose between re-running these automated tests or the manual tests.

Leveraged development practice

Test automation is not just automating your test practice and speeding up some parts of your daily work, it's opening up new possibilities, as obvious as they can be. Just to mention a few:

Not having to manually (re)execute the obvious, ever-reappearing tests opens up room for manual testers to focus on challenging the system, to really try to break the damn thing.As automated tests can be executed by anybody or any automated process, a developer has a new tool at hand while developing the application code with fast feedback: with any change relevant, automated tests can be run to check whether no regression occurs.Test automation needs more details upfront, which will take some more time, but at the same time allows a much better, more meaningful discussion about the requirements; through the test definitions, the requirements are better tested.

Note

You might want to read my blog post for more examples of how your practice can be leveraged: https://www.opgona.training/index.php/2021/02/25/test-automation-its-not-a-buzz-word-but-a-grand-helping-hand/.

Shorter update cycles and the AppSource paradigm

With iterative methodologies – such as Scrum and Agile – and cloud services, it has become a normal practice that updates are delivered with shorter time intervals, leaving even less time to get full manual testing done, by customers and dedicated resources in your team. Clearly, Dynamics 365 Business Central is a part of this story and your app too. As it will also be a part of the AppSource paradigm, where companies around the world use Business Central in the cloud and are able to basically install any app from AppSource and start using it without any formal relation to and instruction from the manufacturer. If the app appears to be buggy, then they probably will just as easily uninstall it and go for another. You cannot afford for your app to be put aside because your testing practice does not fit this reality. In the Software as a service (SaaS) world, automated testing is a must to guarantee a quality product.

Test automation is required(?)

In the first edition, I started this section with:

Last but not least, on this incomplete discussion of arguments on the whys of test automation, and perhaps the sole reason for you reading this book: automated tests are required by Microsoft when you are going to sell your Dynamics 365 Business Central extension on AppSource.

This is no longer the case as Microsoft does not require automated testing as part of the AppSource validation anymore. They, however, strongly recommend … using automated tests, hence the question mark added to the section heading.

But even though Microsoft isn't forcing us anymore, know that our customers will be requesting this from us more and more, seeing that your competitors do practice and provide automated testing. The latter giving your competitor the advantage of having more time to add features and release more often.

Note

Read Krzysztof Bialowas' blog post where he discusses this Microsoft policy change with a reference to the Microsoft communication on this:

http://www.mynavblog.com/2021/02/16/automated-tests-dont-listen-to-microsoft/.

Silver bullet?

Notwithstanding all the above, you might rightfully wonder whether test automation is a silver bullet that will solve everything. And I cannot deny that! However, I can tell you that, if exercised well, it will surely raise the quality of your development effort. As mentioned before, it has the following benefits:

Easy to reproduceFast to executeObjective

When to use automated testing?

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, which has already been tested, is still working as it should, to show that recent modifications have not compromised the existing application.

This sounds logical, but what does this mean when you have no automated tests in place? How do you go about starting to create your first ones? Basically, I would advise you to use the 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 examples of code changes are typical candidates for your first efforts:

After go-live bug fixingBuggy codeFrequently modified codeBusiness-critical code being changedCode with no or low dependenciesRefactoring of existing codeNew feature developmentMicrosoft updates

After go-live bug fixing

An after go-live bug reveals an omission in the initial test effort 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 again.

Buggy code

You have this feature that keeps on troubling 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 get started on your first test suite.

Bugs are a particularly useful starting point because they usually provide the following:

A defined expectationSteps to reproduce the scenarioA clear definition of how the code fails

These are three important elements of automated testing, as you will learn in the next few chapters.

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 the code is modified frequently, then 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 the circumstances, it is unfortunately not always doable. Testing changes made to business-critical code, however, should always be exhaustive; that is, try to cover all scenarios of those processes and define a test for each one of them in your automated testing. You can simply not afford any failures 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 existing code

Refactoring code can be nerve-racking: removing, rewriting, and reshuffling code. 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 already be too late, as too many pieces got broken. Before refactoring any code, grant yourself peace of mind and start by getting an automated test suite in place to prove its validity of the original code. To achieve this, define the business scenarios and create tests for each of those scenarios to prove that the current functionality works. With every refactor step you take, run the suite. And again, to show the code is still behaving the same. This way, refactoring becomes fun. We will elaborate on refactoring more later.

New feature development

Starting from scratch and creating a new feature, writing both test and application code, will be an undeniable 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 application 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 as 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 in terms of introducing errors.

Note

Working on test automation for a new feature will give you the best return on investment. It will lead to a better quality of the code and thus prevent a lot of bugs after go-live/release. But it might be too big a threshold when you start with test automation. Choose one of the above-suggested candidates to start your test automation battle.

What is automated testing?

We discussed why you might want to automate your tests and when to do this, and more specifically, where to start. But we didn't give any thought to what automated testing is. So, let's do that before we conclude this chapter.

With automated testing, we address the automation of application tests, that is, scripting manual application tests that check the validity of features. In our case, these are the features that reside in Dynamics 365 Business Central. You might have noticed that we have been using somewhat different terms for it:

Test automationAutomated testsAutomated testing

These all mean the same thing!!!

On one hand, automated testing is replacing manual, often exploratory testing. It's replacing those manual tests that are repeatable and automatable, and often no fun (anymore) to execute.

On the other hand, they are complementary. Manual testing will still contribute to raising the quality of a feature, making use of creative and experienced human minds able to find holes in the current test design. Automated testing might also include so-called unit tests. These are tests that verify the working of atomic units that altogether make up a feature. Typically, these units would be single, global AL functions – units that would never be tested manually. Ultimately, both manual and automated tests serve the same goal: to verify that the object under test meets the requirements and doesn't do anything outside of the requirements.

Notes

(1) What is exploratory testing? Check out the following link for more information: https://en.wikipedia.org/wiki/Exploratory_testing.

(2) More on unit and functional tests can be found at the following link: https://www.softwaretestinghelp.com/the-difference-between-unit-integration-and-functional-testing/. We will also elaborate more on unit tests in this book.

Some more notes on automated tests

Before we head off to the next chapter, I would like to add a couple of notes on automated tests that haven't been touched on so far.

Automated tests are code too

There is no sense in denying: automated tests are also code. It takes time to design, implement, and maintain them. Like application code, any line of test code has a probability of containing a bug. The challenge is to keep this to a bare minimum. You can achieve this by:

Making the test design a part of the requirements and requirements reviewReviewing your test code like you would want to review your application codeMaking sure that tests always end with an adequate number of verifications

And, please, like any source, put your tests under source code management. They're a part of your product. Make sure to reserve time for this in your planning.

Automated tests need maintenance

Over time, your application changes and therefore the tests that go with it, be it manual or automated tests. Any change in the application, if well covered by test scenarios, will reflect in a number of failing tests as these no longer fit. Even a simple change in the order of the application code can lead to one or more tests falling over.

Testing vs. checking

One of the reviewers of this book, Xavi Ametller Serrat, pointed out the difference between testing and checking. With testing, we investigate and learn, while checking is about confirming and verifying. The first is typically a human exercise, while the second is what we can automate. Given this insight, automated testing should rather be called automated checking. In this book, however, the first term will be used as this links more to a common notice.

Note

An interesting read on testing versus checking can be found here: https://www.developsense.com/blog/2009/08/testing-vs-checking/.

Summary

In this chapter, we discussed why you would want to automate your application tests, and when you might want to create and run them. And, we concluded with a short description of the what – what is automated testing?

In Chapter 2, Test Automation and Test-Driven Development, you will learn about the Test-Driven Development principles and how they can be applied to Dynamics 365 Business Central development that includes test automation.

Chapter 2: Test Automation and Test-Driven Development

It's not uncommon when people talk about test automation (TA) that the term Test-Driven Development (TDD) is uttered in the same breath. And quite often they are used seemingly as synonyms:

But does that make sense?

In this chapter, we will first investigate how one relates to the other and whether they are in fact equal, followed by a more detailed description of what TDD is. After a short discussion on the benefits, we will illustrate how TDD could be applied in Microsoft Dynamics Business Central development. After that, we will discuss to what extent TDD comes into play when you go down the road of test automation.

This chapter covers the following main topics:

TA versus TDDWhat is TDD?TDD – taking small steps