From Customer Wish to Test Automation - The Basics

We are technically fully set to start writing tests at this point. This is because we know how the testability framework functions, we know the test toolkit, we know about the existence of the standard test libraries, and we have been provided with various patterns to allow us to design efficient and effective tests.

But what are we going to test? What's our business case? What are the customer wishes we are going to implement?

In this chapter, we will start applying the principles and techniques discussed in the previous chapters and we will build a number of basic automated tests.

As such, this chapter covers the following topics:

• Test example 1 – A first headless test
• Test example 2 – A first positive-negative test
• Test example 3 – A first UI test
• Headless versus UI

...

From customer wish to test automation

Our customer wishes to extend standard Dynamics 365 Business Central with an elementary feature: the addition of a lookup field to the Customer table to be populated by the user. This field has to be carried over to the whole bunch of sales documents and also needs to be included in the warehouse shipping.

Data model

Even though the purpose of such a field will be very specific, we will generically name it Lookup Value Code. As with any other lookup field in Business Central, this Lookup Value Code field will have a table relation (foreign key) with another table, in our case a new table called Lookup Value.

The following relational diagram schematically describes the data model of this...

Test example 1 – a first headless test

Now, with our backpack full of tools handed over in the previous chapters, and the customer wish defined, we're set to start creating our first automated test.

Customer wish

Let's pick up the fundamental part of our complete customer wish: the extension of the Customer table with a Lookup Value Code field.

FEATURE

The feature we are building with our extension is called LookupValue and the specific part we are now working on is the Customer table. This leads to the following [FEATURE] tag:

[FEATURE] LookupValue Customer...

Test example 2 – a first positive-negative test

This test example does not relate to a new customer wish and no new application code, but is complementary to our first test. It is a rainy path version of the same customer wish leading to a new scenario:

[FEATURE] LookupValue UT Customer
[SCENARIO #0002] Assign non-existing lookup value to customer
[GIVEN] A non-existing lookup value
[GIVEN] A customer
[WHEN] Set non-existing lookup value on customer
[THEN] Non existing lookup value error thrown

Test code

Let's reuse the recipe applied for test example 1.

Steps to take

...

Test example 3 – a first UI test

The field Lookup Value Code had been implemented on the Customer table and tested. But, of course, to allow users to manage it, it needs to be made accessible in the UI. Consequently, it needs to be placed on the Customer Card.

Customer wish

The next stage of the customer wish is very close to the previous part defined by [SCENARIO #0001]. The main difference is that we now want to access a customer by means of the UI element Customer Card. By mimicking end users, our scenario describes creating a new Customer Card (see second [GIVEN]). Have a look:

[FEATURE] LookupValue UT Customer
[SCENARIO #0003] Assign lookup value on customer card
[GIVEN] A lookup value
[GIVEN] A customer card
[WHEN...

Headless versus UI

As mentioned before, headless testing is the preferred mode for automated tests as it is faster than UI testing. With test example 1 and 3, we did implement the same kind of test: check that a lookup value can be assigned to a customer. Test example 1 in headless mode, while test example 3 uses the UI. Running both tests indeed shows that UI tests are slower than headless tests. Have a look at the graph of execution duration (in seconds).

The average execution duration for the UI tests is 1.35 seconds, while the headless average is almost 7 times faster: 0.20 seconds.

Summary

In this chapter, we got to build our first automated tests. We utilized the ATDD test case pattern to design each test and used it as a base structure in our 4-steps recipe to create a test codeunit, embed the customer wishes into a test, write a test story, and finally construct your real code.

In the next chapter, we will continue to use ATDD and the 4-steps recipe to create some more advanced tests.