The best news sometimes go silent, and the newest release of Microsoft Dynamics NAV has just proven this claim.
Ladies and gentlemen, Microsoft Dynamics NAV 2016 comes shipped with full set of application test toolkit, that you can use to test your customizations against regression issues. Even though most partners out there have never even tried the testability features, let alone written a unit test (for all the wrong reasons), testability framework of NAV is one of its strongest points, and was the last missing piece to complete the big puzzle called Road to Repeatability.
The application test toolkit is a set of 693 objects, out of which 669 are codeunits (almost all being test codeunits) There are total of 15879 individual unit tests (all numbers are for W1 version) that test standard application functionality and help you discover regression issues. Running them on a clean “Cronus” database should result in no errors, and running them in customized environments pinpoints any regression issues that cause problems in the standard functionality.
If you look into the database, you won’t find the test toolkit, but if you look into the installation DVD, you’ll notice an inconspicuous little folder named TestToolKit which contains these files:
Import them, and you are good to go.
Application test toolkit is nothing new. It was first released in late days of NAV 2009 with several hundred unit tests (around 490 if my memory serves me well), and was followed soon with around 7900 unit tests for version 2013. However, as time went on, there was R2 and a large number of cumulative updates, all of which rendered the long-released application test toolkit mostly useless.
Microsoft has talked about Road to Repeatability for a long time now, but expecting partners to be truly repeatable, and not arming them with tools to eliminate bugs, was a sure recipe for repeatable problems, not repeatable solutions. Multi-tenant environments should be as bug-free as possible, and being able to discover regression issues was of utmost importance.
I have always been a big believer in NAV testability, and have been evangelizing it ever since it was first released in NAV 2009 SP1. Over the past year I have delivered sessions on testability and unit testing in NAV for partners from 18 countries, and on every single occasion I was faced with a big question mark: why does Microsoft not release the test toolkit for the standard applications? Well, now they have. Late, but definitely not too late.
Even though you may not write your own unit tests (and if you make this choice, it’s for all the wrong reasons) then at least please use the objects provided by Microsoft. They will tell you immediately if you break something, and your developers will know about your bugs before your customers, or support department do.
Pingback: Microsoft Dynamics NAV 2016: What’s New » waldo's blog
Are there any end-users using the Test Toolkit yet? We have the full Solution Developer module, but can only edit or run the test codeunits in the 13nnnn numerical range. There are also a bunch of codeunits in the 14nnnn numerical range (locale-specific I believe) and our end-user license does not allow us to open those codeunits in the Dev Environment or run them inside the test tool (“You do not have the following permissions on CodeUnit xxxxxxxxxx Execute”).
A request for getting our license updated from Microsoft Operations hit a brick wall. Their response was “we have determined that the reason you are not able to access the objects, it is because there are no modules associated with the objects. The objects are only acquired through the Application Test software found on the MSDN website. We tested it out, but it looks like the only way to test with the objects is to use the Application Test Tool…” I guess they are saying that this numerical range of objects isn’t in a “module” that we can add to our license.
Well, I don’t know about end-users. but I know partners are using it all over. This is not intended to be used by end-users. Also, end-user licenses will have all sorts of troubles, not just the one you mention here. Your test code should be license-agnostic, and if you need to test whether the licensing limitations work as expected, you should do it differently.