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

By now, you know how to write your automated tests and have integrated them in your daily development practice. How can you profit from this humongous collateral of tests Microsoft has provided? This chapter discusses why you might want to add them to your own collateral, what hurdles you must take, and how. So, in this chapter we'll discuss:

• Why use the standard tests?
• Executing standard tests against your code
• Fixing failing standard tests
• Disabling failing tests
• It's all about data
• Is it all really about data?

Technical requirements

Like in the previous chapter, we will refer to the LookupValue extension. Its code is to 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 9, How to Integrate Test Automation in Daily Development Practice: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 09 (LookupValue Extension). In the current chapter – Chapter 10 – we will only focus on the Business Central standard tests. We can disregard our own test codeunits, and therefore we can throw them out. We will, however, retain our test libraries.

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 10 (LookupValue Extension).

Details on how to use...

Why use the standard tests?

Ever since they introduced the testability framework in 2009, Microsoft has been building on its application test collateral. As already pointed out in Chapter 4, The Test Tool, Standard Tests, and Standard Test Libraries, it contains an immense number of tests. These tests cover the whole standard application, from financial management, sales, and purchase, through warehouse and manufacturing, to service management. With every major release or cumulative update, new tests have been, and will continue to be, added to cover new features and recent bug fixes. Years of work we all can profit from. If your code extends the standard application, what will the impact be on it?

You could go about writing your own tests. You could also choose to run the standard tests and see the results. And, of course, in the end, you could do both, as your extension most probably will not only change standard behavior but also add new functionality not covered by any test...

Executing standard tests against your code

The proof of the pudding is in the eating, so you can go and verify it by following these steps:

1. Deploy the solution we built and tested in Section 3, Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central, to Business Central.
2. Deploy all standard test extensions and test libraries – see Getting standard test and test library apps deployed in Appendix, Getting Up and Running with Business Central, VS Code, and the GitHub Project.
3. Set up a test suite in the test tool with all present test codeunits, as discussed in Chapter 4, The Test Tools, Standard Tests, and Standard Test Libraries.
4. Run all the tests.

This worked pretty fine on C/SIDE-based versions, but unfortunately, moving forward to newer versions that are AL-based with more and more tests added, the standard test collateral showed to be unstable to some extent. While a standard test run on a NAV 2018 CRONUS, demo company...

Fixing failing standard tests

Now let's have a look at the errors and see which of them relate to the extension. They might already unlock some of their secrets. All errors that relate, about 157 out of the 176, are similar to the following:

Error Message: Lookup Value Code must have a value in Sales Header: Document Type=Order, No.=1003. It cannot be zero or empty.

With also an Error Call Stack that resembles this one:

SalesPostEvents(CodeUnit 50004).OnBeforePostSalesDocEvent line 3 - LookupValue by fluxxus.nl
"Sales-Post"(CodeUnit 80).OnBeforePostSalesDoc line 2 - Base Application by Microsoft
"Sales-Post"(CodeUnit 80).OnRun(Trigger) line 26 - Base Application by Microsoft
"Library - Sales"(CodeUnit 130509).DoPostSalesDocument line 53 - Tests-TestLibraries by Microsoft
"Library - Sales"(CodeUnit 130509).PostSalesDocument line 2 - Tests-TestLibraries by Microsoft
"ERM VAT Tool - Sales Doc"(CodeUnit 134051).VATToolSalesLineWithZeroOutstandingQty...

Disabling failing tests

How about the almost two handfuls of remaining failing tests? These are standard tests that at this moment do not succeed in your environment. Whether it is because they are failing anyway or because they need some specific setup, it's not clear to me. In general, I will just disable them on the assumption that it's a relatively and absolutely small number of tests, and that the remaining successful ones give me a good enough health check of the code. Of course, if time allows, you might want to study them closer, but if the numbers are so low, please ask yourself if spending more time is worthwhile.

Disabling failing tests could be done manually using, for example, the test tool extension. A more repeatable solution, however, would be to use the DisabledTests.json feature provided by the Run-TestsInBcContainer cmdlet of the BcContainerHelper module, or one of the ALOps pipeline steps. To be able to create a valid DisabledTests.json file, you should...

It's all about data

In my experience, getting the standard tests working on your code is mainly about getting the test fixture right, as in the previous exercise. Fixing the error by supplementing the fixture isn't a coincidence. It's the most probable thing that you will be doing in getting the standard tests run on your code: bring the test fixture in the right state.

In this specific case, we fixed the fresh fixture. Running more standard tests will show other kinds of test errors. Solving these errors, however, is again mostly about updating the test fixture, fresh and, in some cases, shared fixture.

Executing and fixing Tests-Fixed Asset

Having run only one standard test app – Tests-VAT – let's see the results of running another one against our code: Tests-Fixed Asset. Some of those failures relate to the LookupValue extension. Apparently, the fix we implemented to tackle the errors thrown on the Tests-VAT test run did not prevent the...

Is it all really about data?

Of course not! But in the majority of the cases of failing standard tests, it worked out that way for the projects I was on. Based on this experience, my best practice in getting a failing standard test fixed is the following sequence:

1. Try fixing the error by adjusting the shared fixture, if that does not do the job adjust…
2. The fresh fixture, if not adjust…
3. The test code, often the verification part. In this case, you hit upon a test code bug. If it is still not working, adjust…
4. The application code. You found a real bug!

This helped me a lot in having the right focus in getting standard tests working on our solution.

Summary

In this chapter, you learned why you would want to use the Microsoft tests, how to start applying them on your Business Central code, and how to fix the most regularly occurring errors they might throw. You learned that most fixes relate to adjusting the test fixture, be it shared or fresh.

With this chapter, the first edition of the book came to an end. In this second edition, we have added a whole new section, Section 5, Advanced Topics, containing three new chapters. There, we will discuss how to construct complex scenarios, write testable code, and test outgoing and incoming calls and how to mock them.