Testability Framework in Dynamics NAV

This afternoon (May 2nd 2017) we are hosting a webinar with NAV-Skills about the Testability Framework. Luc van Vugt will be the presenter and I will do an attempt to moderate.

The testability framework has been with us for a long time and was introduced in one of the last versions of the classic client. Even though it has been with us that long it never got widely adopted either internally by Microsoft and the partner channel.

Until now.

With NAV2017 Microsoft seems to have found a formula that works to ship their tests (18.000+) and partners are looking at how to implement them into their own solution.

This week there was some discussion on Twitter on the testabilty framework. Let’s look at some of them.

So there seems to be a general consensus on the value of the framework.

How to start

One of the questions I hope Luc will answer today is how to get started. What surprised me a little at start was that most of the MVPs seem to have started with the Microsoft tests while I started to write my own test not looking at what Microsoft did and it made me question my approach.

I think the answer can be found in what type of solution you have. Are you making changes to the existing NAV code or are you programming sollely on top of the application.

Recently I’ve created the ForNAV Navision part and I created a test codeunit to verify if the code works and this test codeunit saved my ass a few times already. But for this app I did not touch any of the standard code or influence the standard flow.

What I advise to partners, when they ask me, is to run the standard Microsoft test but not to make changes to it. Once you start changing the Microsoft test codeunits you have to maintain your changes.

I hope after the webinar this afternoon that this was good advise.

If you write your own code as isolated units you can write your own tests against it which is why it is called unit testing. The standard Microsoft code is not written in a modern way but written tightly integrated like everyone did in the 1990ies with ERP applications. This is why the Microsoft test codeunits are sometimes hard to understand. The engineers who created the tests did a great job but their lives would have been easier when the standard code was more componetized.

The standard Microsoft tests should just work and are not to be touched. Write your own unit tests for your own units.

So I am looking forward to this afternoons webinar to see if it will change the way I think about the approach I have been following so far.

Comment List