News

My last demo introduces gulp, an amazingly simple task automation tool. You’ve seen what it is, how to set it up, and how to create a simple hello-world task. Now it’s time to teach gulp…

The post appeared first on .

Get ready for the next big step in taking the control add-in development to the next level. Today, I am (re)introducing gulp. I’ve blogged about gulp in the past, but I’ve never really finished that…

The post appeared first on .

Having been working on a fully automated for the past year using , 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 street. This also includes add-on .fobs delivered by our vendors. So far, we had not included them all as typically these do not change regularly

The other day, however, we did get an update of one of the add-ons and needed to deploy them starting at the D-side of our DTAP street. My first reflex was the old-fashioned way of manually importing the .fob into the database. But wait ... which database? Of course first my D(evelopment) database. No problem. But here my mind did not stop asking: ."And then?" Indeed, T(est), being 3 databases, and A(cceptance), another 3 databases, and finally P(roduction), 2 more databases. Not even including the other D databases of my fellow developers and the updated end-user license. Having , at long last, our automated street in an almost good shape, we had agreed that any deployment should be done using the automation. No manual actions anymore. So, I found out that one of the nuts still needed to be tightened, was to get the add-on .fob included in the build and release pipelines. I was very pleased to find out that it was much simpler than I had thought. Praise to the way the build and release pipelines had initially been setup. Thanx, !

The .fob and the update end-user license got deployed to the various databases quite easily, but then another issue came around, which brings us to the topic of this post. Once deployed our automated tests were triggered resulting in two failing test leading back to the add-on:

• The type of Table xxxxxxxx in Field yy is incompatible with Table zzzzzzzz Field 1
• Assert.RecordCount failed. Expected number of AllObj entries: 49. Actual: 42

Having been around with standard automated tests for a while already, as you might know, I could easily trace these back to the tests ValidateFieldRelationCompatibility in codeunit 134926 (Table Relation Test) and ShortcutDimensionsUpdatedOnDimSetIDValidation in codunit 134380 (ERM Dimension). The later I will leave for now and spend another post on it later. However, regarding the first issue I had to conclude to my dismay that our add-on vendor apparently had never read my first . Which made me immediately wonder if they do have test automation at all!

I reported the issue to vendor and, wow, did get a fix almost immediately returned which I checked into our source repository and got the whole DTAP street automation running. Ouch, a similar issue occurred on another table in the add-on. didn't they still run this test themselves? Shame on you! With the second bug report the "message" had been received as the next returned fix did contain all the fixed tables.

As I concluded the initial how-to post, that  "... if, after all my previous posts on the test toolkit, you're still looking for reasons to start using it ... now you have surely one (more), be it a small, and very useful one." If you want to get your solution converted from C/AL to AL at least run this one test codeunit to be sure that all your table relations are OK. While not yet released as an AL extension you can still change data types like you might have been used to in C/AL. But once an extension has gone live you face the new world we are living in: fields can no longer be changed like you used. Basically, you're stuck with it for a while. And run the test form day one on each of your AL extensions, just to be sure table relations are healthy.

BTW: might a table relation be unhealthy for a valid reason your can exclude it from the test by adding it to the ExcludeKnownInvalidTableRelationsFromBeingChecked function subscribing to its OnAfterRemoveTableRelation publisher. Make that subscriber part of your extension so any time codeunit 134926 is run in an environment with your extension in it it will not fail.

In the last example I put online, we’ve noticed that it was difficult to achieve a good separation of concerns in the front end if we are building UI directly through DOM. Apart from the…

The post appeared first on .