Wednesday, November 28, 2012

Test-Driven Development in AX 2012 - Intro

As much as we all like our product of choice (Dynamics AX) and our jobs (developers, developers, developers, developers), we have to admit one thing: our Dynamics AX industry's professionalism in software engineering principles is at its infancy. From my blog posts about TFS I know there is a lot of interest in source control, and the tooling around it that TFS provides. I also know from the types of questions I get, that there are not a lot of people/companies out there actually using version control to its fullest, some companies aren't using version control at all. For a critical business application that is so technical, that is stunning.

Another topic of software engineering is unit testing. AX has sported a unit test framework for a few versions now, but similar to the version control topic, adoption of this feature is minimal.

So, after picking up some independent background information on unit testing, I decided to apply some of these principles on an internal project building some implementation tools. Granted, technical solutions are easier to test than functional modifications. However, after reading more on the subject, it's become clear that it's all about the approach. Unit testing can influence your design in a good way. Although you don't want to change your design to make it testable, in a lot of cases keeping testability in mind will lead to better design choices, and testability may come almost automatically.

I think for the most part unit testing, its use, and definitely the practicality of test-driven development is a topic for heated discussions and is definitely not a wide-used practice. So, in the interest of getting a debate going, I will publish a few posts on the topic of unit testing and test-driven development.

To get some background info, I purchased the book "The Art of Unit Testing". The main attraction for me was the overall explanation of concepts rather than focusing too much on a specific product, framework, IDE or language (granted, it does say "with examples in .NET" and there are specific uses of frameworks). Some of the reviews complained that the book doesn't go far enough, but I thought it was a perfect introduction to get me going on experimenting with unit testing.
Just to get it out of the way, I do not have any affiliation with the author, publisher or I did like the book as an introduction, but your mileage may vary.

Stay tuned for detailed examples and suggestions for all your unit testing needs :-)


  1. Hi Joris

    "...we have to admit one thing: our Dynamics AX industry's professionalism in software engineering principles is at its infancy..."

    If AX developers would stop using the good old "dangling" semicolon after variable declarations, it would already be a big progress, I think...

    The main problem is that a lot of people are lazy, and they don't even think about learning/trying out new methodologies. I wish all my colleagues were eager to learn new things as much as you do :)

    Looking forward for your new posts.


    1. Aaah, yes, the semi-colon. Sometimes it's just a force of habit though, I sometimes have to remove it when I'm reviewing my own code. After 10 years of semi-colons, it's hard to quit that habit.
      However, did you know you still need the semi-colon if your first statement is a call to a .NET static method? Try it! It won't compile properly unless you have a semi-colon to separate the declarations!!

      Laziness, perhaps. For the most part it's historical laziness and as you say people are not willing to try out new methodologies. Most of those methodologies have been widely adopted in other software engineering industries. But AX... not yet.

      I predict that with the next release of AX it will be do or die as far as adopting these better practices. (Admittedly I had already expected some of that in this release, and it hasn't happened yet.)

    2. I didn't know that there is a case when the semicolon is needed :), now I would know what was going on should I encounter that situation, thanks.

      There is another issue with UTs here. It may be difficult to explain to customers why they should pay for the time the partner spent for unit tests. At MS, they do understand that UTs are needed in the longterm perspective. But end customer management may be resistant to these methologies just because of immediate cost.

  2. I completely agree - unit testing is extremely important and it's an integral part of many projects that take quality and efficiency seriously (sadly, not in AX). The positive impact to design is also indisputable - I'm myself sometimes surprised how unit tests led me to a better design than I originally intended.

    Nevertheless, we have several challenges in AX:
    1) A lot of development in AX are changes to existing code and it's often difficult to write test for the change, if no tests for the original solution are available. And a lot of code is virtually untestable.
    Microsoft (Mr. Pokluda few years ago) claimed that they have many tests, but they don't want to publish them because the quality doesn't meet usual criteria for production code and partners have too many changes anyway. I still think that this would be the most important single step to promote unit testing in AX.

    2) It's difficult to work with database in unit tests. The usual answer is mocking, which is not applicable in AX (more about it later). We have some test isolation in SysUnit, but it's still not satisfactory. I believe you either need to maintain a set of test data, which requires a team effort (therefore I haven't seen any team doing that, because only few individuals care about unit tests), or you always have to prepare all data for a test, which is quite cumbersome.

    3} What greatly simplifies design for testability and what's essential when working with legacy code are mocking frameworks (there is one attempt for AX, SysMock, but the project is abandoned). They allow to mock all objects used by the tested class (without excessive subtyping or dependency injection), so you can test the unit without additional references. Check moq (, for example.
    And I have no idea how it would be possible to mock direct SQL commands in X++ (extract all of them to separate methods actually decrease quality of the desing). I considered some ways how to use mocking frameworks at least for X++ compiled to CIL, but it's still just an idea.

    At the end, I write unit tests mainly if the problem is too complex for manual testing - and I don't count that anybody will maintain the tests in future, because the culture does not exist in AX...

    By the way, don't miss the classic in the TDD area: the Kent Beck's book.

  3. Hi Joris, Hope you doing well. A huge thumbs up for your great work.

  4. Microsoft Dynamics AX 2012 is an ERP system for mid-size to large companies. Also, I want you to write a post about What are the various versions of Microsoft Dynamics AX? I asking you just because I'm sure that you've got a full command over this topic.

    I'm sharing with you here 3 best ways your Medical Website could have a great impact on the profit of your healthcare business.