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

Getting the hang of it by now? Well, you did get this far, right? How about doing it TDD way now, putting test first all the way? And while doing that I'll supplement your toolbox with some more test tools for Microsoft Dynamics 365 Business Central. In this chapter, we'll expand on how to:

• Refactor your code (Test example 7)
• Test a report (Test example 8)
• Test with permissions (Test example 9)

But before we do, let's review the previous test examples in the TDD light.

Technical requirements

Like in the previous chapter we will refer to the LookupValue extension. Its code can be found on GitHub: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition.

In this chapter, we will continue on the code from Chapter 7, From Customer Wish to Test Automation – Next Level: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 07 (LookupValue Extension).

The final code of this chapter can be found in https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 08 (LookupValue Extension).

Details on how to use this repository and how to set up VS Code are discussed in Appendix, Getting Up and Running with Business Central, VS Code, and the GitHub Project.

TDD and our test examples

After I introduced the concept of Test-Driven Development in Chapter 2, Test Automation and Test-Driven Development, I did not pay any attention to the topic until now. In fact, I deliberately evaded to use TDD as our way of working for mainly one reason:

To write automated tests for application code that already exists.

This is most probably the context in which most of you will start applying test automation.

Now, what if you had applied TDD to our test examples?

To be honest, it wouldn't have looked much different, as a lot of the TDD principles were implicitly exercised by:

• Defining your customer wishes by means of the ATDD scenarios, you created yourselves a sufficient set of tests, that is, a test list.
• Implementing your tests with the 4-steps recipe.

With the latter, we:

• Took small steps.
• Created a structure for each test based on the GIVEN-WHEN-THEN tags.
• Constructed the real code to get it to work...

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...

Test example 8 – how to test a report

Reports have always been a substantial part of many Business Central projects and solutions. It makes perfect sense to have a look at how to test them in an automated manner. But how do you go about doing that? In this example, you will learn how to test the dataset being created by a report by inspecting its XML structure. Layout testing is another job to do, and, unfortunately, one outside of the testability framework.

Customer wish

Your customer's wish describes that the Lookup Value Code field of the customer must be carried over to the various sales documents. The logical consequence, even though not explicitly stated, would be that each printed version of these documents would have to be extended with this field. As sales document reports are quite comprehensive, both on the dataset and on the layout side, we take a simpler example.

We'll clone report 101, Customer - List, and add the Lookup Value Code field to...

Test example 9 – how to test with permissions

When implementing the customer wish, the focus is on getting the resulting new functionality working, irrespective of if you go down the test first road or not. With testing, we verify if this new functionality is working as intended. This does, however, not necessarily mean that all Business Central users will be able to operate this new functionality as this also depends on the permission sets that have been assigned to them.

As you might know, the most basic level at which we define permissions is the table data level. When introducing a new table in your extension, like the Lookup Value table in the LookupValue extension, you also need to provide at least one permission set that defines the access to the table data. And like with any feature you provide; you should also test whether the permission set works right. How to do this that's what this test example is about.

In order to enable a user to access the data in...

Summary

In this chapter you built tests the TDD way, using the red-green-refactor mantra. But before you did that, you cleared the refactoring backlog for all the tests you have been constructing so far in the previous chapters. Based on this clean slate you applied TDD to testing a report dataset and permissions.

In the next chapter, Chapter 9, How to Integrate Test Automation in Daily Development Practice, we step into the fourth part of this book, in which we will discuss how to integrate your test automation in your day-to-day development practice, including the tests provided by Microsoft.