Dependency injection

Read more about the article Testing in isolation

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

Directions EMEA 2023 demo – decoupling base app

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

Here we go. As promised, I’ll start with the demo I delivered at my “Mythbusting code coverage” session at Directions EMEA 2023 in Lyon.

Over the course of this year, I have talked about testability at 12 sessions at 7 events, 6 public one-day and two-day workshops, and 4 private direct-to-partner one-day workshops. At all those sessions and workshops, almost all of my demos are “made up”: they are code examples written by me to illustrate the concept I talk about in an easy-to-follow way. I think they work quite well to show you what my goal is and what and how I am doing what I am doing.

And yet, I have faced criticism that goes along the lines of “all nice, but this is oversimplified fake examples, and it’s easy to create those examples for just about any concept you want; why don’t you do it on a real-life example, it’s probably not going to be possible.”

Well, I disagree, and that’s why for this event I have decided to add one more example to my example suite, and show how you can apply all the concepts I talk about to a piece of existing base app code, all while not breaking anything and not having to change any other area of the code that depends on that refactored code. Here you can find that example, explained step by step.

(more…)

Continue ReadingDirections EMEA 2023 demo – decoupling base app
Read more about the article Fun with Interfaces: Testing

Fun with Interfaces: Testing

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

Oh how much fun we had today on my live stream, it’s just amazing. First, all the viewers had fun of waiting for me to go live for nearly an hour, and then at some point I managed to unplug my reflector. Perks of live streaming 😁

First of all, I would like to – once again – apologize to everyone who waited for me to go live. I’ll explain in the end of this blog what really happened. For now, let’s go on-topic.

(more…)

Continue ReadingFun with Interfaces: Testing
Read more about the article Fun with Interfaces: Patterns

Fun with Interfaces: Patterns

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

Today I had my fifth live stream. The topic was interfaces, and this time I took a different angle at it: patterns. When I polled about live stream topics you’d like to hear about, most of you said “patterns”. So today’s stream covers several patterns and puts them in perspective of interfaces, or the opposite way around, however you like it.

The stream is available on my new http://vjeko.live/ page, and here it is if you hate clicking.

(more…)

Continue ReadingFun with Interfaces: Patterns

I had a dream: decoupled NAV

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

You know about PRS (Partner Ready Software), don’t you? It’s the initiative started by Mark Brummel, Eric Wauters (Waldo), and Gary Winter (not necessarily in this order), and then they decided to expand their team by one more member. I am not quite sure if this was a good move, but the time will tell. It always does.

The main goal of the initiative is to enable you to customize NAV in a repeatable way. Repeatability is kind of a buzzword, but PRS doesn’t just buzz the word. PRS believes repeatability is the key. Today maybe you don’t care about repeatability. In two years, or latest five, you’ll want to go back and rethink your angle. PRS wants you to rethink now.

One way of getting repeatable customizations is through patterns. There are patterns, all over NAV, that repeat, time after time, over and again. Agosto dopo agosto dopo agosto dopo agosto as Jovanotti would put it. Pun intended. When a pattern repeats itself, it’s repetition, not repeatability. There is a big difference between them, big as a house. To get repeatable, is to get rid of repetition. Instead of having essentially the same piece of code all over the place with a hint of Goldberg Variations, how about having it only once, in a single place?

Like, having one place where you assign a number from a number series to any master record, document, journal, you name it. Instead of at least—let me guess—120 different places in about as many objects. Then, if you want to customize one small aspect of it, you just touch that one single place. You can then repeat the same customization for hundreds of customers, not only surviving the version upgrade, but making it (the upgrade) an essential, non-disruptive, piece-of-cakeish part of your service offering. That’s the repeatability that PRS is all about.

But—there is always a but—the way NAV is today, we are a long way from this kind of repeatability. A long and painful way away.

That’s why I had a dream. I know it’s only a dream because to make NAV do what I am about to share here would be to downright rearchitect it from the core. But I’ll share it nonetheless. Keep reading.

(more…)

Continue ReadingI had a dream: decoupled NAV