PowerShell: Run Script Error: Exception setting "CursorPosition"
Poisson d'Avril - The Sequel, part #9
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 I also would be again part of this more than interesting group of people. No direct message from MS so far, but the MVP site clearly congratulates me with my MVP Award. Yesssss. For the 9th time.
I always wonder if my community work of the past year is worth another reward. As there are no strict rules to what you should have done. No dashboard displaying gauges that indicate my level or progress during the year. In the end it's a couple of persons at MS that, based on your achievements, pass the judgement. Apparently for the 9th time they have found my activities worth an award. Thanx for that. It's still a joy to be part of this.
Congrats to all my peers that have been "renewed".
And regarding the title of this post: "Poisson d'Avril - The Sequel, part #9". Just like it and it relates to the previous posts on the same subject.
A book, conferences and workshops
If you read 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, , Netherlands
I wil present .
May 24, 2019, , Odense, Denmark
I wil be presenting with Erik Ernst and Palle Arentoft on how to speed up your development including automated testing.
June 27/28, 2019, , Southampton, UK
A two days workshop with a lot of hands-on.
And if your interested to join a workshops somewhere else, please let me know. At this very moment I am trying to set up one in , but my feet, car, the train and/or plane can bring me anywhere.
A book and the things unsaid
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 , 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 . Having been a tester in the Global Localization Development team at Microsoft (and having too leave to just when we were getting into test automation) the inner testing fire was lit again by 's NAV TechDays 2011 presentation . And I have kept it glowing, and got it burning more and more over the years past. By blogging, by talking at various conferences, and not the least, by pushing automated testing into the development practice of my main employer, (TLN). Against the flood in the early years, as little to none of us seemed to dare to step into it. Well. except Microsoft, but, yeah, Microsoft, that's not us and they initially did not make it easy for us to get on it.
You know, I already launched the idea of a book on test automation to Packt in November 2011, but, sign of the time, it was never picked up. Disappointment? Well, in way, yes, but you know, I still have the portfolio manager among my contacts on LinkedIn. I am not a real hard-hearted guy. I surely do not want to be one.
All the years following there wasn't a real change in how automated testing was looked upon. True, it did evolve; maybe I contributed to that. I hope I did, sure. But like many others Packt did not react. Until last summer. Even though I knew I was going to put me up with a hell lot of work, I also knew the tide was the right one: Microsoft enabling us more and more, more people picking up, and not the least AppSource requiring test automation. So I reposed my idea of a book on test automation to Packt and Packt agreed. Yeah, I could have done it on my own, like various others do and to whom I have been looking with all repsect, but I needed others to get those things organized that I would have had a hard time to manage while also focusing on the designing, coding, writing, and reviewing. Being a quality focused person, both with respect to the product and the process, there is a lot of things at Packt I kicked against, but I am sincerely grateful for their "dedication and endurance", as I wrote down in my original acknowledgement, but which did not make it as it was beyond the 450 allowed maximum number of characters. Here starts the part for which I am mainly writing this post, being the...
Things left unsaid
...in the book due to protocols at Packt and the scope of the book.
I owe a lot to my two major contacts at Packt: Roshan Kumar (Content Development Editor) and Snehal Dalmet (Technical Editor). I know I haven't made their lives always easy as I had clear ideas on how I wanted to put things down. Both of them have done there utmost best to go with my flow and still justify things within the Packt protocols. Working remotely I did not have the fortune to meet them live, but I recon that some times the go-with-Luc's-flow did make steam escape from their ears. A big bow towards you both, Roshan and Snedal.
The proof is in eating the pudding as we say, and this surely applies to the topic of the book. The knowledge that I am sharing with you is based upon a lot of things I learned from others by reading, arguing and listening. But it has matured by having been able to apply it in real live. For that I owe my main employer, TLN, and specifically my team, Team Dynamics: Bert Kootstra, Gert Kleinjan, Jack Reitsema, Marcel Müller, Martijn de Blaauw, René Brummel en Stefan Venhuizen.
Another major influence to the book, who als fell of the 450-characters-including-spaces table, is my peer MVP James Crowter. A great, a tall, a knowledgable, and a challenging guy. The guy with whom I did the 2017 NAV TechDays presentation on test automation, in retrospect an important step in cristalyzing my thoughts and ideas that made it to the book. And not the least James the owner and managing director who apparently has the gift to form a great team around himself and invests in them. For the latter he asked me to introduce his whole team to test automation and about a year ago I performed two functional and two technical workshops with them, including James himself (and the other James who was a reviewer and wrote the foreword to the book). It was a great experience with all this dedicated and jolly nice people, and learned me a lot. It also brought me to the from customer wish to test automation concept for a number of presentation and the key part of the book.
Topics that did not make the book
Approx. 200 pages is a lot of space to fill when you start. A huge fan of Kansas when an adolescent returned in my conscious a zillion times when writing, and still a vast amount of pages to go. Nevertheless the pages got filled and some topics had to be left untouched, among them the following:
- Using SQL queries when wanting to inspect the data created
- Making your tests and helper functions extendable
- Elaborate the TestPage more extensively
- More on the automation of a test run
Let's see if I can find time to get back to so more frequent blogging, or others to step in, like James Pearson did with respect to the last bullet: .
I guess I have said what was left unsaid in the book. I sure hope, when you acquire the book, it helps you get on test automation as we need to, our clients need us to! And even more: I hope you can enjoy it as much as I do.
Debug without publishing
Indeed UI testing is slow
.. 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 time I learned that UI tests roughly take a factor 10 longer compared to an equivalent headless test.
I knew the results and saw the differences at a high level, but I had never, I have to confess, measured it myself. Until recently, working on my book on automated testing in Business Central. And still working on it.
See the test results of a simple scenario populating a lookup field through code (headless) or a (UI). The average duration of the headless test yielded 0.20 seconds vs. 1.35 seconds for the UI test. Not exactly a factor 10, but quite close to it.
Indeed you will have valid reasons to build UI tests, mimicking on a testpage what a user would do, but I hope you do consider the speed of headless tests and make a balanced spread of your tests over UI and non-UI tests. And you know, testing a process doesn't need UI interactions, in general. And hell, yeah, bear in mind that your test collateral will grow over time, and continue to grow, and thus also the total execution time of all your tests.
How to install Docker on Windows 10 without Hyper-V
How-to: Decompile your .app file
The other day we found out that some part of one of our extensions was not uploaded to our source code repository and no local version was available anymore. But we did have the .app file. I knew from extensions version 1.0 that the extension file, the .navx, was a zipped set of files. The x in .navx is pointing at this is with all office file extensions now a days. You might recall one of my . As per this blog post, but then in reverse order, would I be able to unzip the .app file by changing the file extension to .zip? And subsequently use the Windows Extract All feature? Apparently not:
So, my lazy mind thought: it can't be done this way, and I asked on one of the fora I am whether there is another way of decompiling a .app file. Of course, on the Extension Management window there is the feature Download Source:
Indeed this gives you a nicely zipped file set:
But what if I really only have the .app file an nothing more? Bruno Leisibach and Peter Sørensen helped me out. Thanx, guys.
The .app file is indeed a zipped set of files. Whereas my simple trick did not work, just use a program like and extract the files. Note however that the format of the files and the project structure is not exactly the same as when using Download Source. The app.json is now a NavxManifest,.xml (where do we know this from?).
Download Source is somewhat differently implemented on NAV 2018 and Business Central:
- On NAV 2018 you can download the source if the extension has been installed on a specific tenant
- On Business Central it will only work when showMyCode is set to true in your extension and the extension has been built with target set to Internal.