Testing in isolation

  • Post comments:14 Comments
  • Reading time:40 mins read

An AL developer gets fired from his job for writing inefficient tests. With his LinkedIn profile proudly showing off his extensive testing experience, a car manufacturer hires him to test cars. His first assignment: test the oil lamp. So he imagines a test, applying his vast experience:

// [GIVEN] A car
// [GIVEN] Enough fuel
// [GIVEN] Engine oil within operational limits
// [GIVEN] Engine runs long enough

// [WHEN] Oil level drops below operational minimum

// [THEN] The oil lamp turns on

Spoiler alert: the guy’s gonna get fired again.

(more…)

Continue ReadingTesting in isolation

Gentlemen’s agreement pattern, or handling the “Handled” pattern

  • Post comments:9 Comments
  • Reading time:13 mins read

I’ve delved deep into design patterns story with my last two blog posts, but I am far from over. The patterns I discussed are the ones we could use up until NAV 2015 (we can still use them, of course!) but some more robust loose coupling (excuse the near-oxymoron) can be achieved with what NAV 2016 brought along: events.

It’s the “Handled” pattern. This pattern comes from Thomas Hejlsberg, a chief architect and CTO of Microsoft Dynamics NAV, and was first described by Mark Brummel on his blog. It’s a powerful loose-coupling pattern that successfully addresses the shortcomings of all design patterns I discussed earlier. I would prefer calling this pattern Event Façade rather than “Handled”, but it’s not my baby to christen.

Let’s take a look.

(more…)

Continue ReadingGentlemen’s agreement pattern, or handling the “Handled” pattern

10 reasons that make design absolutely necessary

  • Post comments:6 Comments
  • Reading time:14 mins read

Unfinished buildings, by net_efekt (on Flickr)Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.

As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.

Here I list the ten most important reasons that I believe make design absolutely indispensable.

(more…)

Continue Reading10 reasons that make design absolutely necessary

Setup-dependent requirements

  • Post comments:5 Comments
  • Reading time:4 mins read

While designing a custom functionality for a customer, there was an issue with posting groups: the way the custom functionality was designed would result in value entries being always posted to a single posting group, resulting in inventory balances always going to the same inventory account.

When I brought this issue to my customer’s attention, they said: “but we only have one single inventory account, and we only use one single posting group, so we don’t need this functionality to be smart about this”.

This was an example of what I like to call setup-dependent requirements.

(more…)

Continue ReadingSetup-dependent requirements

A new book about Microsoft Dynamics NAV

  • Post comments:3 Comments
  • Reading time:3 mins read

Back in my time (now I feel old :)) if you wanted to read a book about Microsoft Dynamics NAV, you just couldn’t—there wasn’t any available. Today, if you want to learn about NAV, not only there are books about programming and implementing, but with new Mark Brummel’s book you can now learn about the most important aspect of Microsoft Dynamics NAV customization projects—the application design. The book hasn’t yet been published, but is already available for preorder through PACKT Publishing at the following link: Microsoft Dynamics NAV 2009 Application Design.

(more…)

Continue ReadingA new book about Microsoft Dynamics NAV