Blog

Extensions are a hot topic these days. There was a ton of sessions at both Directions events, likely also at NAVUG, and most of the talks you could hear while mingling around was extensions this, extensions that.

Chances are – you are going to be writing your extensions in a foreseeable future.

However, there is a catch with extensions – while it may be easy to load them up into an environment, unlike Cronus database your extensions must populate the database with their own demo or starter data. Otherwise, they will be pretty much useless.

Depending on which version you are on, this may be a simple task or a not simple task.

If you are on NAV 2017 and above, then rejoice. Extensions can now contain their own starter data that is a part of the extension .navx package and that’s loaded into the database when extension is installed.

However, if you are on NAV 2016, then you have to take care of this manually.

After my Directions EMEA session about test-driven development, I was approached by Mirosław Malinovski, who shared his idea about how the standard Test Toolkit libraries can be utilized for initialization of default data.

And here I share it with you. It’s simple: instead of writing your own functions that create all those various kinds of entries, why not tapping into a library of 600+ codeunits with thousands upon thousands of functions that create just about any standard record in the application and expedite the process at least a little bit?

There is a caveat: there is no guarantee that the Test Toolkit will be available in the target environment. In fact, it’s very unlikely it will be available (that’s why Microsoft is not shipping it as a part of the database, but ships it separately so you can install it in development, test, staging, etc. environments, but not production environment). So, to be on the safe side, use the library as the starting point: take those functions from it and put them into your codeunit and off you go. It can easily save you hours of manual coding.