Automated Tests in AL

The purpose of this article is to show you how Automated Tests help you write cleaner code.

Introduction

Automated testing is not new in Business Central, in fact, automated testing was introduced in Microsoft Dynamics NAV 2013.

Let us start by looking at why other people think Automated Testing is a good idea.

Automated Testing is a Good Idea

It is a Requirement

Automated testing is a requirement for getting your app on the Microsoft AppSource, aka. Business Central App Store.

A good argument, but hardly explaining why it is a good idea. But this is the reason why ISVs finally got started on it.

Everyone does it

Though this is not true for C/AL and AL projects, it is definitely an integrated part of modern development frameworks like Ruby on Rails.

Test Driven Development

Luc van Vugt is a former colleague at the Microsoft Global Localization Team. Luc has a lot of experience with testing and I highly recommend reading his book: Automated Testing in Microsoft Dynamics 365 Business Central.

Luc gives all the classic arguments for why testing is a good idea.

  • Your dependencies on Microsoft updates
  • Refactoring of existing code
  • Business-critical code being changed
  • Buggy code
  • Frequently modified code

And I agree, these are valid points. But …

Automated Testing in the Real World

When did automated testing help me for real?

I found the bug while writing the test

When you are writing the test function, you have to understand what the function is supposed to do. Once I was asked to write a test function for a function written by a colleague. I found the bug, just by designing the test function.

Automated Tests before Refactoring

This is the more common scenario. I decided to write the automated tests before making a major refactoring of some code. This caught several bugs and made the development much faster.

New Feature Introduces a Bug Elsewhere

New functionality can interfere with other parts of the application. Especially when several developers are working on the same project. When development gets more complex, and functions more complicated, it is important to put in safeguards. The more business-critical the function is, the more tests should we write for it.

But they are all missing the point

Once a superior asked if we could outsource the writing of automated tests. It makes sense. Our developers want to focus on the fun stuff and writing tests is boring. Right? Maybe we could get someone cheaper to write the tests and the Sales Team want us to ship more features in the product.

If you look at all the above arguments and good ideas, there is nothing saying that outsourcing the task is a bad idea. But it is a bad idea. It is, what I often call, a false good idea.

Automated Tests changed the way I write code

Writing automated tests made me a better programmer. And this is what I want you to take with you from this article.

When is the right time to write tests?

With Test Driven Development (TDD) you would write your tests before you start programming. But often you will postpone the writing of tests, because you need to focus on the deadline and it can wait till later.

But in both cases, it misses the point.

Write the test and the function in parallel

Let robust and beautiful code be your guide.

When you are writing code, you want it to be easy to read. This means splitting your code into functions that each has a specific purpose.

When doing this, ask yourself what would be a good name for this function. What does it do and what is the result of the calculation?

When the code is easy to read, it has been broken into functions with a specific purpose and these functions can then be tested.

Now when you are writing the function, you know that you are going to write test functions that will, by all means, try to make your function fail.

So while writing the function, you start by writing a positive test. Something simple. The typical scenario for that function. Then you write some negative tests, trying hard to make your function fail. Then you step up the safeguards of your function. Then you write some stress testing. Putting pressure on your function. Tests that get out on the edges and in the corners of the domain (integers, dates, codes, string sizes) your function is operating on. Then you make your function robust and fight off these attacks.

Now when you look at the result, you have beautiful code, well-organized functions, that are so robust that you can through anything at them.

This is why we have to write automated tests and why we have to do it in parallel.

So that we get robust beautiful clean code. Easy to read and easy to maintain.

Clean AL Code Initiative