From Customer Wish to Test Automation - Next Level

In the previous chapter, we built our first basic test automation in Dynamics 365 Business Central. We 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, we will use the same methodology to create some more tests that:

• Use a shared fixture
• Are parametrized
• Hand over variables to UI handlers

Sales documents, customer template, and warehouse shipment

With the three examples of Chapter 5, 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 describes clearly 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 case for the application...

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 per the [GIVEN] tags, being 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...

Test example 5 – how to parametrize 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 parametrize a test function, but you can achieve this by encapsulating your generic test code in a helper function.

Customer wish

Let...

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. However, the platform does, and the argument list is a fixed one.

Customer wish

In this context, we 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, the user has to select a template to base the new customer on (or simply bypass it by selecting Cancel), as shown in this screenshot:

We've had to tackle the appearance of the ModalPage already in test example 3 of the previous chapter...

Summary

By building three more test examples, we learned how to set up a shared fixture, how to parametrize 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 workout a more complex scenario.