Sunday morning, sun softly touching me while I am sitting behind my laptop at the other end of our kitchen table. Time to write the post that has been on my mind for quite a while. A topic partly born out of amazement. An amazement triggered every once in a while when hearing fellow professionals saying that it does not make sense to run the standard tests [1] on your solution. Our daily practice shows different for already more than three years. That's what I would like to share with you below…

Over almost a decade I have been evangelizing test automation by blogging , presenting at various conferences and webinars, workshops, and, eventually last year, writing a book . People are picking up, but it's clear there is still "a war to be won". Testing, more specifically test automation, is too often considered a cost center instead of an essential part of our daily development practice. In my joined article with Global Mediator, called From a testing mindset to a Quality Assurance-based…

When working on getting the standard tests running on our solution the standard Test Tool was not making our live as easy as it could. Wanting to rerun only successful or failing tests, this was near to impossible. Manually deselecting individual tests turning of the Run field, was, euphemistically said, not the most meaningful thing to do. So, already a couple of years ago we decided to add some actions to the test tool allowing us to (1) select the Run field for (a) all tests (b) only failing…

Overtime I have been advocating the use of the standard Business Central tests in various posts, webinars, conference presentations, and my book . IMHO this has been, and still, is an undervalued collection of over 22,000 automated tests that cover all functional areas. It's a no brainer to let them run on your solution as we did on ours . In case your solution intertwines with standard code chances are big that these tests will also hit your code resulting in a number of failing tests. As discussed…

Those of us that have been around long enough will remember that Microsoft Business Solutions-Navision 4.0 came out with the new XMLport and MenuSuite object types. I can clearly remember a sort of astonishment about this UI-less XMLport. To allow you to feed this "pipeline" with data you had to wrap it in another object. Where Dataports had Request Forms like reports the XMLport totally failed this. And if you wanted the user to provide input, you would typically wrap the call to the XMLport…

Together with Global Mediator we start a series of blogposts about QA for Dynamics channel. The idea was born when both I and my Global Mediator friends came to the same conclusion: test automation is still not really taking off in the Dynamics NAV/BC world, let alone quality assurance. So we sat down and started a joined project which we baptised: QA, the ugly duckling . Through this we want to sharpen our minds and at the same make you, our readers, part of it. Let's see how this first stone…

While developing your own extension on NAV 2018 or "BC under version 15" you have the availability over 2 debuggers: the VSCode debugger and the C/SIDE (or should we call it Windows) debugger. Both serve a somewhat different scenario: VSCode debugger You want to run step-by-step through the code of your extension - being AL code - and from there might step into the code that resides in the NAV/BC installation you are programming against. Most probably the C/AL code of the standard application…

Having been working on a fully automated DTAP street for the past year using Azure DevOps , we are now getting in the phase of tightening the last nuts and bolts . This typically is about completing some part of the automation still, but mainly it's about getting all the sources in the right place. And with all the source I do mean all the sources. Any source that relates to some part of our solution and needs to be deployable in whatever part of our DTAP street, should become part of this automated…

Sitting in the train up North on my biweekly trip to my main employer I came across Tobi's early tweet: A big joy that this great technical mind and very nice fellow human, will be MVP for another year. He's worth so much of it, like various other MVPs. And ah, yes, July 1, which since two year now has become the regular renewal date of the MVP Award. No longer April 1 as it used to be for a quarter of the MVP's, and me belonging to the same batch. Automatically the question came to mind whether…

If you read my book and want to confront me live, or too lazy to read it (yet) and want to hear me speaking or teaching, or you did not get to buy the book yet, you will have a number of chances to do so: May 18, 2019, 365 Saturday Amsterdam 2019 , Netherlands I wil present Test Automation for Business Central . May 24, 2019, Days of Knowledge , Odense, Denmark I wil be presenting with Erik Ernst and Palle Arentoft on how to speed up your development including automated testing. June…

You might not have noticed anything about it yet, but after 260 hours, spread over 5 months, of designing, coding, writing, and reviewing on my side, my first book , and the first book on test automation for Microsoft Dynamics NAV / Dynamics 365 Business Central has been released last week. Finally, a wish came true, an ambition, started probabably back in 2011 with my series on NAV and Test-Drive Development . Having been a tester in the Global Localization Development team at Microsoft (and…

.. compared to non-UI, or so-called headless, testing. That was one of the major reasons that the testability framework was added to the Dynamics NAV platform back in 2009 by MS. It replaced its predecessor, the NAV Test Framework (NTF). NTF was a C# based test framework that allowed you to script test in C# against the NAV UI. Having 40+ country versions to handle, and a couple of major releases, running thousands of UI tests took simply too long to check each country-version build. At that…