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

In the previous chapter, you built your first basic test automation in Dynamics 365 Business Central. You looked at three simple examples that show how to apply the Acceptance Test-Driven Development (ATDD) test case pattern and our 4-steps recipe to get customer wishes converted into an application and test code. In this chapter, you will use the same methodology to create some more tests that use the same test data setup, that have a comparable structure, and that interact with UI handlers.

The following topics will be covered:

• Sales documents, customer template, and warehouse shipment
• Test example 4 – how to set up a shared fixture
• Test example 5 – how to parameterize tests
• Test example 6 – how to hand over data to UI handlers

Technical requirements

All test example 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 with the code from Chapter 6, From Customer Wish to Test Automation – the Basics: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 06 (LookupValue Extension).

The final code for this chapter can be found in https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 07 (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.

Sales documents, customer template, and warehouse shipment

With the three examples in Chapter 6, From Customer Wish to Test Automation – the Basics, we added the Lookup Value Code field to the Customer table. However, that's just a part of the customer wish as it clearly describes that:

"… this field has to be carried over to the whole bunch of sales documents and, at the same time, it needs to be included in the warehouse shipping."

So, before we dive into the following test examples, a note needs to be made that parallel to the implementation of the Lookup Value Code field on the Customer table, the same field has to be implemented on the Sales Header table, the Customer Template table, the Warehouse Shipment Line table, and all related pages. The ATDD test case descriptions are very much alike, and this will be the same for the application and test code. Copy and paste – the great virtue of any Business Central developer.

Let's have...

Test example 4 – how to set up a shared fixture

Although it isn't explicitly mentioned, we created a fresh fixture for each of the three previous tests as defined as per the GIVEN tags, a lookup-value record, and a customer record. For speed purposes, however, it does make sense to consider whether you need a fresh fixture for each test or a shared fixture for a group of tests. In the case of scenarios #0001 and #0003, we could perfectly do with the same LookupValueCode, no need to create a new lookup value record for each of these tests.

Customer wish

Let's use the part of the customer wish that prescribes to have a Lookup Value Code field on all sales documents to illustrate how a shared fixture can be achieved. This would come down to the following eight scenarios, leaving out the GIVEN-WHEN-THEN part to save space:

[SCENARIO #0004] Assign lookup value to sales header
[SCENARIO #0005] Assign non-existing lookup value on sales header
[SCENARIO #0006] Assign...

Test example 5 – how to parameterize tests

Writing test automation, including design and coding, is a considerable effort, which has a lot of details to pay attention to. However, once you've got the hang of it and have it in place, you will enjoy it and continue to profit from it. This is the case unless you're sloppy on the details at both the design and coding levels, and thus have to keep fixing your tests.

Nevertheless, you will enjoy writing even more if you make your tests generic by parameterizing them. By the nature of the testability framework, you will not be able to parameterize a test function, but you can achieve this by encapsulating your generic test code in a helper function.

Customer wish

Let's illustrate this with another part of our customer's wish: archiving a sales document. As Business Central enables the user to archive a sales quote, a sales order, and a sales return order, we have to include this in our extension. This...

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

Just now, with the previous test example where we hit upon the need for two dialog handlers, it makes sense to discuss how to hand over data to a UI handler, as we cannot directly control this. It's the platform that controls this, and we have no way of passing any additional data.

Customer wish

In this context, let's pick up another part of our customer wish – when creating a new customer from the UI, by clicking the standard New action on the ribbon, you have to select a template to base the new customer on (or simply bypass it by selecting Cancel), as shown in Figure 7.6:

Figure 7.6 – Select a template for a new customer

This part of the customer wish tells you that the configuration template that's behind the templates you can choose should be set up so that it will auto-populate the Lookup Value Code field on the newly created customer from the selected template...

Summary

By building three more test examples in this chapter, you learned how to set up a shared fixture, how to parameterize tests, and how to hand over variables to UI handlers. These are three techniques that will be of invaluable worth in your future test automation practices.

In the next chapter, we will add two more tools to your test toolkit. You will learn how to test a report dataset and how to work out a more complex scenario.