Van Vugt's dynamiXs

As more people are starting to get into test automation, my book is being used more and more. And as time is moving on it gets outdated more and more, unfortunately. Because of this I have asked my publisher almost a year ago to update the content to be fully in sync with the current state of the product. To no avail (so far). As part of an internal project at one of the Dutch Microsoft Dynamics 365 BC partners I will be training their developers on this topic and for that have provided them…

You might know that I have been (and still am) a fan of Statical Prism . But now that we moved into the AL world this is becoming obsolete as it only handles C/AL code. Christin Clausen and his stati-cal team have been working hard on the AL version of the tool. Last week they released a preview version of Prism for AL to the community and they asked me to review it. Unfortunately I did not find enough time yet to that, but had a quick look and thought it very promising. And as such worthwhile…

CODE COMPLETE! Yesss. This was waiting somewhat too long on my desk to be completed, but this morning I finally did: Extended Text on Assembly Documents . This example extends the standard Extended Text feature in Business Central to assembly documents. As with the previous two completed examples ( Blocking Deletion of Warehouse Shipment Lines and Automatically Set Posting Period on GL Setup and User ) you will find a full collection of ATDD scenarios in Excel and PowerShell files, that were…

A couple of months ago I introduced here my GitHub project Test Automation Examples when I had just finished the first example as a spinoff of my new online course. And around that time I started with example 2 . Test wise this one was a bit too ambitious and as a consequence it is still waiting to be completed. Hopefully somewhere during my long summer recess I get it done. Meanwhile, at my major employer, I designed a nice new feature with a bit more restricted scope than example 2 which this…

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…