Software Engineering

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.

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.

Okay. There has been a lot of “long time no see” intros to my posts on this blog in the past, but never this long. So – looooooong time no see, folks! We may have seen at other places I have been active – which obviously wasn’t here – so you know that I have not been gone fishing since my last blog, but I think it’s now really about time I restart.

It has again been a while since I blogged – or video-blogged for that matter. I won’t offer any excuses – I’ve been very busy over the past month. I delivered two public webinars, both of which were fully booked and ended up very successful. The first one was Leveraging Git , and it was the first public redelivery since January.

If you have ever worked with Microsoft’s Team Foundation version control tools, it wasn’t easy to switch to Git. That’s not because Git was complicated – no, nothing like that at all! It was simply because you had to forget almost everything you thought you knew about version control, and then learn it anew.

One thing we learned from lessons learned is that we don’t learn from lessons learned. Somebody, alegedly I don’t know where this quote comes from, a one-minute googling didn’t reveal it to me (but it isn’t mine, I’ve read it somewhere for sure). Anyway, a month ago I started live streaming .

Source code files are living things. We add new ones and change their content on daily basis. Occasionally we delete them, too. Git is amazingly efficient when it comes to tracking these kinds of changes. However, sometimes we need to change the file name, or file path, or both.

In the last post , I explained how to use tasks, but I didn’t explain yet how to make them useful. Tasks are most useful when they automate certain file operations, and gulp helps with reading and writing files. However, if you need to perform a transformation, then you need to look for plugins that can get that work done for you.

Now that you know how to get gulp up and running in VS Code , and how to export tasks from your gulp file , let’s talk about tasks themselves. What are they, what are they good for, and how to write them. Gulp – being a task automation tool – is all about tasks.

In my last post I covered the very basics of getting started with gulp in VS Code. It was all about getting gulp up and running under the hood of VS Code, and about writing your very first gulp task. It didn’t do much, but it showed you what gulpfile.js is good for and how to export tasks from it, that you can later use from VS Code.