On July 22, 2026, the French Minister of Transport, Philippe Tabarot, answered a citizen’s question on the French government’s participation platform Agora. The answer, in short: No. Tesla FSD (Supervised) will not be authorized in France. Not yet.

You can watch the video with the minister’s answer on the Agora platform, and the decision was covered widely in the French press, for example by Le Figaro and Numerama. The Danish motoring organization FDM writes Tesla-ejere i Danmark får lov at slippe rattet, and the official website of Færdselsstyrelsen announces Teslas førerassistentsystem FSD Supervised er foreløbigt godkendt i Danmark.

I live in Denmark, and here FSD (Supervised) was provisionally approved on June 9, 2026 by the Danish Road Traffic Authority, Færdselsstyrelsen. The Netherlands was first, on April 10, 2026, when the Dutch vehicle authority RDW granted a European type approval with provisional validity limited to the Netherlands, after more than one and a half years of testing. Lithuania, Estonia, and Belgium followed.

The minister’s answer reveals a lot, and that is what this article investigates.

The question from Ludovic

Supervised autonomous driving, approved in the Netherlands, could help save lives by limiting human error. Is France considering authorizing it soon?

The full transcript of the minister’s answer, translated into English, is at the end of this article. Read it. It is worth your time.

Intro: I bought FSD in 2019

In 2019, I bought a Tesla Model 3 and added the FSD option. I have been waiting for seven years!

What does it mean to me?

Driving from Denmark to France

I never thought of letting the car drive in the city. My interest was letting it drive the 1.200 km on the highway from Denmark to France. That would have been really useful.

If FSD cannot cross the borders into Sweden, Germany, the Netherlands, Belgium, and France, then it is just a gadget.

People who are blind or have low vision

My son was slowly losing his vision at that time, and I told him that by the time he turned 18 in 2026, they would have solved the challenge and that one day, he would be able to own a car. Little did I expect that public administration would get in the way of the technology.

Safety

In 1987, my mother was killed in her car when a truck driver lost control of his vehicle. To me, it is personal, and I have no problem with all trucks becoming autonomous.

Electric Car

I have driven almost 200.000 km in my Tesla Model 3. Assuming a comparable gasoline car consuming 5 liters per 100 km, that corresponds to roughly 10.000 liters of gasoline that would have had to be pumped out of the ground, refined, and transported to a gas station. Burning that gasoline would have produced about 23 metric tons of CO2 in tailpipe emissions alone. The comparison covers tailpipe emissions only and does not include the emissions from producing the electricity I charged with.

Everyone else is late to the party

Tesla

Tesla has been talking about self-driving cars since 2016. All of their models, including the cheapest Model 3, have been equipped with cameras and an onboard computer intended for self-driving since 2017, though the hardware has been upgraded several times since then.

On the Tesla AI Day 2021, they shared progress, data, problems, and information.

Tesla does not publish a cumulative figure for its FSD investment, but my estimate is that the company has spent more than $14 billion on AI infrastructure, research, and development over the past 10 years. Not all of that is FSD-specific, but the order of magnitude is clear.

The European Union

Now that Tesla is actually rolling out FSD Supervised on public roads, Europe is reacting, or should I say panicking.

The good news is that the EU understands that it has to harmonize the rules for all countries. No European car maker will ever succeed in making autonomous vehicles for all the different countries in the world. Especially the small ones. This should also be good news for human drivers and other car makers.

2025-03-05 Industrial Action Plan for the European automotive sector

Get the PDF here.

2026-06-08 Directorate-General for Mobility and Transport

18 Member States signed a Joint Declaration of Intent on large-scale cross-border testbeds for autonomous vehicles.

EU Ministers back cross-border initiative for autonomous vehicle testbeds

Note that as a first supporting measure, the Connecting Europe Facility (CEF) 2026 work programme foresees 20 million euros for digital infrastructure dedicated to autonomous driving under the reflow call to be launched in June this year.

Twenty million euros will not get them far. Tesla, a single company, has had to spend billions of dollars, and even Tesla is not there yet.

Why are we interested in autonomous vehicles?

Autonomous vehicles can save lives

That is the promise, according to Elon Musk on X, and it is the reason Ludovic asked his question in the first place.

Some people cannot or prefer not to drive a car

• People with low vision or other disabilities
• People who have a driver’s license but are not comfortable driving
• People with no driver’s license

Protection of the European car industry

This looks like protectionism to me. France, Germany, and the other car-making countries in Europe have strong industrial reasons to delay Tesla, and I suspect that protecting the European car industry is part of the explanation.

The minister presents this as a pure safety decision. But notice that the countries that approved FSD first, the Netherlands, Lithuania, Estonia, Denmark, and Belgium, have one thing in common: none of them has a major national car brand to protect.

You need data to train AI

The car industry and the minister are overlooking something fundamental about AI: you need data to train it on.

In October 2016, almost ten years ago, Tesla announced that every car leaving the factory would be equipped with eight cameras and the hardware for full self-driving. Tesla has been collecting real-world driving data ever since. Its camera-equipped fleet has driven billions of kilometers, and Tesla can select and upload the real-world driving clips that are useful for training. It does not need to transmit every kilometer to learn from the fleet.

European car makers also collect driving data. But none of them combines Tesla’s fleet scale, standardized hardware, and nearly a decade of continuous deployment. Without comparable data, I do not see how they will catch up.

In the video, the minister reminds us that France has some of the best engineers in the world. That is true.

But this is not a traditional engineering problem. You cannot specify, design, and engineer your way to autonomous driving.

Without data, there is no AI. And you cannot buy ten years of driving data. You have to collect it.

This only concerns a few cars anyway

The current European rollout only concerns the newer Tesla models with Hardware 4. And the customer has to pay a subscription of 99 euros per month to activate FSD.

That will further limit the number of users actually activating FSD in France. We are not talking about millions of cars suddenly driving themselves. We are talking about a small, careful, and paying group of early adopters.

The driver is responsible

This is important, and the minister actually says it himself: FSD (Supervised) is a driver assistance system, not an autonomous driving system.

The driver has to be in the driver’s seat, pay attention, and be ready to intervene at any moment. The driver remains fully responsible, including legally, even when FSD is activated.

So the safety net the minister is asking for is already there. It is the driver.

Once approved, the customers will move

In the Q2 2026 earnings call, held the very same day as the minister’s video, Elon Musk said:

We’re seeing in locations that have FSD approved, we’re seeing a very high take rate of FSD. In fact, I think for a lot of people, they’re actually buying Tesla Full Self-Driving with a car attached, as opposed to a car with FSD.

Customers are walking into the stores asking for Full Self-Driving, with whatever car it comes with. About 55% of North American deliveries in Q2 had an FSD subscription enabled at the time of delivery.

This supports the point. Once FSD is approved in Europe, the rest of the car industry will lose even more customers to Tesla. The French car industry knows it. The German car industry knows it. And I suspect the minister knows it too.

Delaying the approval does not change this. It only delays the moment the European car industry has to face it.

The minister’s answer (full transcript in English)

Here is the full transcript of Philippe Tabarot’s video answer, translated into US English with my comments.

Hello everyone, I am very happy to answer today a question that has attracted a lot of interest: Ludovic’s question about Tesla’s FSD driver assistance system.

So that everyone understands what this is about: this system is a driver assistance system developed by Tesla for its vehicles. It is a very advanced driver assistance system whose goal is to drive in all environments, executing all maneuvers automatically and driving hands-free. Until now, these driver assistance systems were mostly oriented toward highways, and in general, at least one hand must remain on the steering wheel. So this is a significant change.

At least Tesla is getting the credit that their system is very advanced. Well, they spent billions of dollars over 10 years on a bold prediction.

The Netherlands has decided to depart from the international and European regulatory framework and authorize its use on their territory.

Unbelievable. Mr. Tabarot is criticizing the Netherlands for moving forward. For reference, see the RDW explanation of European type approval Tesla with provisional validity in the Netherlands.

In France, we consider that this system brings a certain number of technological advances, but that the trade-offs in terms of safety are not yet sufficient for an authorization as it stands. Especially since this system is not an autonomous driving system: the driver remains responsible for driving the vehicle at all times, including when FSD is activated.

This is strange and in contradiction to the RDW: “Safety is RDW’s top priority.” and “We have thoroughly examined and verified this system for more than one and a half years.”

Moreover, several other European countries share these reservations about the system’s level of safety. Our position is therefore not isolated.

Why is it necessary to emphasize that France is not alone? This is completely irrelevant.

So what are these concerns? Without going into overly technical details, there are several. First example: we have found that the system allows speeding. If it notices that the vehicles around it are driving faster, in plain terms, it can drive at 70 km/h instead of 50 if traffic is moving at that speed, and this without any explicit request from the driver. In some cases, a vehicle can thus go up to 50% above the authorized speed limit. The rules of the road are therefore not respected.

I find this argument absurd, and much of the reaction on social media has been the same. The system acts human-like, drives like anyone else would, yet you argue that FSD should “police” the other drivers. Nonsense. It makes no sense to make such requirements.

Another example: according to the data we have, the system does not guarantee an optimal level of driver attention in the city and during the most complex maneuvers, such as lane changes, crossing intersections, or roundabouts. Yet a lack of attention can have very serious consequences, both for people outside the vehicle and for its occupants. And let me remind you: even when the driver assistance system is activated, the driver remains criminally liable in the event of an accident.

We are talking about FSD Supervised. The whole point is that the driver is responsible and present.

Philippe Tabarot says no to Tesla FSD on safety grounds, while he has earlier acknowledged that drug use is a growing problem among drivers in France.

To understand this, I invite you to read a post from Philippe Tabarot on LinkedIn one year ago.

Il y a 3 mois jour pour jour, Joana, 15 ans, perdait la vie à Châteaudun dans un accident de car scolaire.

Exactly three months ago today, 15-year-old Joana lost her life in Châteaudun in a school bus accident.

The driver’s positive cannabis test revealed an unacceptable reality: drug use, a scourge in our society, can also affect those responsible for transporting our country’s primary school pupils and middle and high school students.

This is unacceptable for families who place their children, in complete trust, in the care of school transport professionals.

Would you rather put your kid in a French school bus or in an autonomous Tesla?

By the end of August 2025, nearly 30.000 school bus drivers had been checked.

• 119 tested positive for drugs;
• 63 tested positive for alcohol;
• 337 other offenses were reported.

These people are driving your kids to school! These are not average drivers.

So what are the next steps? We are currently continuing our technical discussions with the Netherlands, the other European states, and Tesla to refine our analysis. Last week, a representative of the Ministry of Transport actually traveled to the Netherlands.

Wow. One person went to the Netherlands. I am not impressed.

I want to emphasize this: France supports these technologies, and their deployment must take place within a framework of trust that makes it possible to evaluate the systems and determine the adjustments to FSD needed to guarantee a high level of safety.

I am sure they do.

Ludovic, I hope these explanations help you better understand the ongoing debates. At a time when the number of road accidents is rising again, my responsibility is to enable innovation without ever compromising on safety. Driver assistance systems as advanced as Tesla’s are new because they are designed to operate in all driving environments, including in the city, where situations are particularly complex. It is therefore normal that we take the time to evaluate them properly, to protect the driver as well as all road users.

I think there are some important observations here:

1. How many Teslas with FSD activated would actually be driving around in France? Tesla is a fairly expensive car in France, and paying 99 € per month for the feature will definitely hold some back. Also remember that only the newer cars with Hardware 4 can activate the option.
2. We can conclude that only fairly rich people with newer cars will actually buy it, and eventually use it some of the time.
3. So how high is the actual risk that Tesla FSD causes an accident compared with all the accidents happening in France?

See last section.

France has always supported the deployment of new driver assistance technologies. We have already granted exemptions in the past for this type of system when it met the safety requirements. This is the case, for example, with Ford and, recently, BMW. And we must look even further ahead: the goal is to move from driver assistance to autonomous driving. In France, more than 200 autonomous vehicle experiments have been carried out since 2015. That is a solid foundation, but I want to go further and enable the arrival of type-approved autonomous vehicles in France as early as 2027.

So we have to wait until next year.

It is in this spirit that France, together with Germany, Luxembourg, and 15 other countries, has launched the European test site initiative for autonomous vehicles. The goal is to harmonize the rules between countries and enable their large-scale deployment across Europe in complete safety.

This is great news. Actually, the only thing to be excited about.

In the fall, I will bring together the French autonomous vehicle ecosystem to present the levers that will accelerate the deployment of this technology and set a course for the coming years.

Now this is interesting. He is delaying Tesla FSD until next year and gathering the French auto industry in the fall. I will be looking forward to seeing what comes out of this.

In France, we are fortunate to have world-class car manufacturers and automotive suppliers, but also some of the best engineers in the world in the field of artificial intelligence and digital technology. We have a real card to play, and we will be there, but never at the expense of safety on our roads.

And in the end, I believe this is what it is all about: the French automotive industry is behind.

Yes. France has world-class engineering universities and Grandes Écoles. France has engineers and mathematicians. France has Mistral.ai. France might even find some money, and it has electricity.

What FSD is up against: the French driver

The French government publishes an annual report on traffic violations. The Bilan 2024 des infractions au code de la route from the national road safety observatory (ONISR) gives the reader a true picture of what FSD is up against: the human French driver.

In 2024 alone:

• More than 27,6 million traffic violations were recorded.
• Approximately 1,1 million of them were criminal road offenses (délits), an increase of 9,5% from 2023. Of these, 25% concerned driving without insurance, 18% hit-and-run (délit de fuite), and 14% driving without a license or with an invalid license.
• 13,9 million automated speeding notices were issued.
• More than 270.000 automated notices were issued for running red lights or railway-crossing signals.
• 11,7 million license points were withdrawn: 5,7 million for speeding, 1,9 million for failure to respect priority rules, and 1,7 million for using a phone or earphones behind the wheel.

And here is the number that should keep the minister awake at night: only 79% of all French drivers still have all 12 points on their license. Among the presumed perpetrators of fatal accidents, only 49% did.

It gets worse. In 2023, traffic offenses accounted for 42% of all criminal convictions in France, and 58% of those involved driving under the influence of alcohol and/or drugs.

And who are these convicted drivers? The report answers that too. In 2023, 205.536 men and 21.473 women were convicted of traffic offenses. 91% of all convictions concerned men, and 52% concerned men between 18 and 34 years old. Men account for 92,4% of the convictions for driving under the influence of drugs, 91,9% for driving despite a suspended license, and 88,2% for drunk driving. The age profile is just as clear: driving without a license peaks among the 18-24 year olds, driving without insurance and driving despite a suspension peak among the 25-34 year olds, and drunk driving is concentrated among the 25-44 year olds.

FSD has no gender and no age. It does not turn 19 and start showing off.

Now go back and read the minister’s main argument again: FSD might drive 70 km/h in a 50 zone if the surrounding traffic does. The surrounding traffic. The one collecting 13,9 million speeding notices a year.

FSD does not drink. It does not take drugs. It does not text behind the wheel. It does not lose its license. And it does not deliberately flee the scene of an accident. FSD can make errors, but not for the same reasons as human drivers.

This is my answer to the third observation above. The question is not whether FSD is perfect. The question is whether it is better than this.

Conclusion

I want to give the minister, Philippe Tabarot, credit for one thing: he answered a citizen’s question, on camera, with arguments. That is how a democracy should work.

I am also happy that the EU is harmonizing traffic rules. It will benefit everyone.

But EU bureaucracy does not advance technology. It has never invented anything. It makes rules.

As the joke goes:

• America innovates
• China copies
• Europe regulates

The old continent is living up to its reputation once again.

BusinessCentral.LinterCop is deprecated and ALCops is the new sheriff in town.

Well, actually, there are six:

Motivation

If you need to know more about the motivation for this change, you can find the explanation in Stefan Maron’s article Introducing ALCops and watch this video on YouTube: ALCops: LinterCop’s Successor for Business Central AL Code Analysis

Migration from BusinessCentral.LinterCop to ALCops

I have made an enhanced version of the LinterCop Migration Script, which you can find on GitHub here: https://github.com/finnpedersenkazes/LinterCop-Migration-Script.

Original: https://alcops.dev/docs/lintercop-migration-script/

Installation

Find the VS Code extension on the Visual Studio Code Marketplace.

Or install it directly from Visual Studio Code.

Source: Getting Started

Don’t forget to uninstall the BusinessCentral.LinterCop extension.

Setup

Look for ALCops in the menu bar at the bottom of VS Code or open the Command Palette (Ctrl+Shift+P) and search for ALCops. Then select ALCops: Select Code Analyzers.

settings.json

{
    "al.enableCodeAnalysis": true,
    "al.codeAnalyzers": [
        "${CodeCop}",
        "${UICop}",
        "${PerTenantExtensionCop}",
        "${analyzerFolder}ALCops.ApplicationCop.dll",
        "${analyzerFolder}ALCops.DocumentationCop.dll",
        "${analyzerFolder}ALCops.FormattingCop.dll",
        "${analyzerFolder}ALCops.LinterCop.dll",
        "${analyzerFolder}ALCops.PlatformCop.dll",
        "${analyzerFolder}ALCops.TestAutomationCop.dll",
        "${analyzerFolder}ALCops.Common.dll"
    ],
    "alcops.automaticUpdates": true,
    "alcops.updateNotification": "notify-only",
    "alcops.versionChannel": "stable",
    "alcops.checkUpdateInterval": 24,
    "al.backgroundCodeAnalysis": "Project",
    "al.browser": "Edge",
    "al.ruleSetPath": "../.BlueCircle360Certified/Level-4/Main.ruleset.json",
}

Don’t forget to remove the old BusinessCentral.LinterCop settings.

What is new?

My code is normally warning-free.

So what did ALCops detect in my recent project?

I have now started reviewing these cases to better understand what should be done.

Conclusion

AL code analysis helps you keep your code cleaner, safer, and faster.

It helps you find problems early, which will save you time and money.

But more importantly, it creates a coding standard for your team, for now and in the future.

Clean Code is about respect for the developer coming after you.

Reach out to me if you need help getting started with AL code analysis.

Observations

FC0004 Permission declarations should be ordered alphabetically

I ended up disabling FC0004 in my permissionset.al files because it conflicted with auto save.

LC0095 Parameter is not referenced

LC0095 had to be disabled in EventSubscriber Codeunits because most functions don’t use all parameters.

PC0037 Use Validate() instead of direct field assignment

PC0037 forced me to move all TableRelation properties from Table Fields to Page Fields, which probably is a good thing.

The TableRelation property provides two things. Control that the value is already in the related table and a lookup link. I needed the lookup link, so I moved the property to the field on the page. I am not testing the page.

I am writing super fast tests using Temporary tables. Using Validate() everywhere collided with checking Table Relations on the table. Since I aime for 100% code coverage of the objects I test, I moved the Table Relation property to the page.

I prioritized to keep my tests simple and fast, at the expense of having to keep track of the Table Relation on both the Card Page and the List Page. I hope I made the right decision.

Recommendations

How to disable a rule in a special case

Sometimes you have to accept an antipattern or wait for the base application to catch up.

LC0088: Prefer Enum over Option type

In this case, the base function only accepts an option. For readability, I have given it one.

#pragma warning disable LC0088
    [NonDebuggable]
    internal procedure CreateHash(TextJson: Text; SecretKey: SecretText) Hash: SecretText
    var
        CryptographyManagement: Codeunit System.Security.Encryption."Cryptography Management";
        HashAlgorithmType: Option HMACMD5,HMACSHA1,HMACSHA256,HMACSHA384,HMACSHA512;
    begin
        Hash := CryptographyManagement.GenerateHash(TextJson, SecretKey, HashAlgorithmType::HMACSHA256);
    end;
#pragma warning restore LC0088

Event Subscriber Codeunit

Always keep your Event Subscribers in a dedicated Codeunit.

LC0095: Parameter is not referenced

Typically, you are not using all the parameters the Event Publisher is offering, therefore you need to disable the rule.

Start and end your object file with a #pragma warning to disable the rule for the entire Codeunit.

#pragma warning disable LC0095

codeunit 50000 "Event Subscribers"
{
...
}

#pragma warning restore LC0095

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL
• Part 8: There is a new sheriff in town

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

We are at an inflection point

I am just back from Directions EMEA 2025 where I have spoken with a number of people who show the way forward.

Maybe the inflection point was there before, but AI has definitely made it more obvious.

Artificial Intelligence is the asteroid hurtling down and hitting our ecosystem.

Business Central is fundamentally different from Dynamics NAV

It is an error not to make enough sense of urgency.

This is not just about upgrading from Dynamics NAV to BC. Business Central development is fundamentally different from Dynamics NAV development, and this difference is accelerating.

The upgrade cycle has changed forever

In Dynamics NAV, you could upgrade every five or ten years. You had time. You could write code that worked, even if it didn’t follow best practices. The upgrade cycle was slow enough that technical debt could accumulate without immediate consequences.

Business Central changes the rules completely:

• Monthly updates: Your code is updated every month, whether you like it or not
• Breaking changes: With two major releases per year, breaking changes arrive on a regular basis

The problem isn’t new—it’s just more urgent

The truth is, Dynamics NAV had programming guidelines. Microsoft provided them. But many developers created their own patterns, and it worked because upgrades were rare.

That approach is much harder to sustain now.

When you’re facing monthly updates and breaking changes, code that doesn’t follow modern practices becomes a challenge. It can break, cost more to fix, and frustrate customers. And it may put you at a competitive disadvantage.

The customer perspective

Customers are often unaware of the technical debt hidden in their codebase. They don’t know to ask for:

• Code that follows Microsoft’s guidelines
• Test coverage
• Modern architecture patterns
• Regular code reviews

They trust that “senior developers with a lot of experience” are delivering quality code. But experience without modern practices can sometimes lead to legacy code.

The AI acceleration

The world is moving fast. AI tools are making it possible to build better solutions faster. Competitors who adopt modern practices and leverage AI will outcompete those who don’t.

If you’re still writing code the Dynamics NAV way, you may find yourself falling further behind every month.

What modern Business Central development looks like

Modern BC development requires:

• Investment in training: Understanding BC’s architecture, not just porting Dynamics NAV code
• Test-driven development: Writing tests that run in milliseconds (see my articles on Environment Interfaces and Temporary Tables in Tests)
• Code review: Peer review of all changes (see my article on How to make a code review)
• Modern tools: CodeCop, linters, proper settings.json configuration (see my article on Advanced Rulesets)
• Clean architecture: Namespaces, interfaces, proper organization (see my Clean Code Initiative)
• Engineering management: Teams that understand modern software development

The cost of delay

We’ll upgrade to BC during the next two years.

But in two years, everything will have moved so far from where we are now. This year alone has seen rapid changes. Waiting two years means you’ll be even further behind, with even more technical debt to address.

The time to act is now.

How to identify legacy code patterns

After three years as a freelance BC developer, I’ve seen patterns that suggest code may not be ready for BC’s update cycle:

• Objects organized by Object Type instead of functionality
• Global variables everywhere
• No test apps
• Minimal or missing settings.json configuration
• No CodeCop or other linters
• No use of interfaces or namespaces
• Inconsistent naming conventions
• No automatic code cleanup
• No peer code review process

If this describes your codebase, it is urgent time to get started fixing it.

The path forward

I have changed my job title to Modern Business Central Developer.

Prefer to rewrite code using modern patterns rather than patching old code.

If you have adopted a modern development mindset, then show it by changing your job title to Modern Business Central Developer.

And, please, by all means share this article with your network and ask your network to join the movement.

We need to outcompete legacy practices

The best way to make legacy practices obsolete is to outcompete them.

By using the latest technologies and a modern mindset, we will build better solutions faster.

Solutions that are:

• Easy to maintain
• Prepared for evolution
• Easy to extend
• Easy to support
• Ready for BC’s update cycle

Reach out if you need help with the transition.

Finn Pedersen

Modern BC Developer

PS: I realize that some people might be offended by this post. That was not the intention. The purpose of this post is not to offend anyone, but to create enough sense of urgency. The technical reality is that BC’s update cycle requires modern practices. The longer we delay, the more expensive and difficult the transition becomes. I want to help, not criticize.

An app says more than a 1000 words

If you are not a developer, you have to try Lovable.dev!

The reason is that it will expand your view on what is possible.

This is what you will learn from making apps with Lovable.dev.

• How to express an idea
• How to reformulate and clarify your thoughts
• How to communicate your idea to others
• Understand how your first hypotheses had flaws and can be improved

To help you get started, there are some examples below.

Lovable.dev

Use my referral link to get free credits when you sign up.

https://lovable.dev/invite/8e75e0e5-5de0-4a7f-860d-3f192c0714f1

And don’t forget to publish your app. It will give me 10 credits to build more fun games.

Team Building

I recommend vibe coding for team building.

People who don’t know how to code often have fewer ideas for what is possible to make. No longer.

After a few attempts you will rapidly get the hang of it.

The hottest new programming language is English

I will be giving a talk on Vibe Coding at the Directions EMEA 2025 conference, 4-6 November 2025 in Poznan, Poland.

More information about the conference at www.directionsforpartners.com/emea2025 and my session.

Snake Game

Build a Snake game for my phone as a web app

Extra instructions

The game must not end. When the snake reaches the edge it should just continue on the other side. Start with a length of 3. Add buttons on the right hand side. The swiping up and right did not work as expected.

Make the head of the snake blue.

mobile-snake-play.lovable.app

Converting French to Braille

Make a small web app that converts a text as I type it to braille. I want the braille to be above the text input field so I can see it as I type on my phone. The braille should not be abbreviated. I expect to write in French. ...

braille-ahead-typer.lovable.app

2048 Game

Make a 2048 game that runs on my phone.

Extra instruction

Swiping works left, right, and up. Swipe down refreshes the page.

twenty-forty-eight-slide.lovable.app

Whether we are just coding with AI or entirely Vibe Coding, we face the same challenges.

The term Vibe Coding went viral in February 2025 and now everyone is talking about it or trying it out.

I have submitted a talk, Vibe coding. The hottest new programming language is English on this subject, to Directions EMEA 2025

There is actually a lot we can learn from vibe coding:

• How do we communicate our needs to the AI?
• Is that similar to how we communicate with a developer?
• What is easy and what is difficult in programming?
• Are some programming languages more suited for development with AI than others?
• Do you need to be a developer to do Vibe Coding?
• How much coding do you actually need to know to succeed with vibe coding?
• Is vibe coding just for fun or can I use it in my work?

What is Vibe Coding?

Computer scientist Andrej Karpathy, a co-founder of OpenAI and former AI leader at Tesla, introduced the term vibe coding in February 2025. The concept refers to a coding approach that relies on LLMs, allowing programmers to generate working code by providing natural language descriptions rather than manually writing it.

Source Wikipedia Vibe Coding

The snake game

Here is an idea for a prompt:

Make the snake game in Elm as we knew it from the old nokia phones.

• Download and install Cursor
• Setup your development environment
• Write your prompt

40 minutes

Within 40 minutes, I had a running game on my computer. I was super optimistic. Take into account that I was also playing, I mean testing, the game during that time.

Then …

Several days later

The app was only running on my laptop and I wanted it to work on my phone. This is where the troubles started. I refused to touch the code. I had to prompt my way to the result. However, at one point, I had to study the code and specifically ask it to change some of the CSS.

I also had to rollback the code completely a couple of times.

Try it

Warning: It is quite addictive.

Project on GitHub

Elm Snake Game on GitHub

The main branch is the first desktop version and the mobile-first branch is the mobile-first version. Feel free to star the project and clone it.

You can follow my dialog with the AI in the cursor_create_a_hello_world_app_in_elm.md file.

It is the entire dialog to get to the first version. You don’t want to see the second. It is too long.

The readme.md is also almost entirely generated with a few prompts stating the sections.

Cursor.com

I used Cursor.com, the AI Code Editor, to realize the project.

I did not write a single line of code, so I did not care about setting anything up.

Programming Languages

Are all programming languages born equal for AI peer programming and Vibe Coding? They are not. Actually, this will challenge our common worldview on programming languages.

What if another language will challenge C# or TypeScript simply because the AI works better with it? Could a small and rather unknown language like Elm suddenly spring into popularity because it works much better with AI?

Some really interesting articles have started to appear.

• Elm as target language for vibe coding by Wil Chung
• The AI Symbiote: Why Deterministic Languages Are the Future of Coding by Le Jon

This is the reason why I chose Elm for my first vibe programming project.

Elm

A delightful language for reliable web applications.

elm-lang.org

Elm is a pure functional language for building interactive web applications. The model-update-view architecture has all state management handled in a single model. The strong static type system guarantees no runtime errors. And I just love the helpful compiler messages and easy-to-read code.

If it compiles, it works.

As it turns out, the AI in Cursor also likes the helpful error messages from Elm.

Try Elm

There are a couple of ways to try out Elm. Here are a few.

• elm-editor.com
• ellie-app.com

Other languages and AL

Since the amount of open source code for a given language is also important for training the LLM, the most popular languages like JavaScript, TypeScript, and Python have an advantage.

A purpose-specific language might also have some advantages. AL is purpose-specific.

AL and AI

Age and how much a language changes plays a role. AL is old and has evolved a lot. There is no tradition for open source projects on GitHub, best practices were not followed, and the language has evolved a lot. For example, we no longer write Find('-') we write FindFirst(). So the LLM has to discard what was good in the past and now considered bad.

Where Elm has been stable for the past five years.

AI assistance helping the AI

When I had trouble with the Mobile-First UI of the Game, I found that the Inspect function in Chrome has an AI assistance. I asked how to fix the issue and passed the advice directly to the AI developer in Cursor. Nice!

Conclusion

Are you in a team? Do you work with developers, project managers, product owners, users, or managers?

Here is what you should do: Make a team-building event and vibe code something together.

You will learn much more than you could possibly imagine.

Warning: You will have so much fun that you will have a hard time getting back to work.

Have fun and learn

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a condition for writing good tests, but it does not guarantee code coverage by tests.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Temporary Tables will satisfy the need for speed and isolation from the database.

Avoid Touching the Database in Tests

We have looked at Environment Interfaces and how they save us time and improve speed, but there is one more thing to avoid during tests: touching the database. Here, we have to think differently—we are not going to develop an interface toward the database, and we don’t have to.

If we want to run hundreds of tests in seconds, we have to change the way we write functions. While the Clean Code Initiative told you to stick to the standard patterns, we are now going to challenge this a little bit in some cases.

Pure Functions

First of all, we want to have pure functions—that is, functions with no side effects. Touching the database is a side effect.

This has important consequences for where we place database operations like Record.Get(), Record.Modify(), Record.Insert(), and Record.FindSet() in our code. In this project, they are now all at the top level.

Passing Records by Reference

To achieve fast, isolated tests, we use temporary tables, which run entirely in memory. When a function operates on a temporary record, you must pass that record by reference using the var keyword. This ensures that any changes made to the record inside the function are retained and that the function works with the same in-memory instance. In the example below, both EncodePhoneNumber and the helper method GetPhoneNumber take Setup as a var parameter, allowing the test to run against a temporary, in-memory version of the table instead of querying or modifying the actual database.

internal procedure EncodePhoneNumber(var Setup: Record Setup; ObjectKey: Text; PhoneNumber: Text; var Object: JsonObject)
var
    PhoneNumberAsText: Text;
begin
    PhoneNumberAsText := this.GetPhoneNumber(Setup, PhoneNumber);
    Object.Add(ObjectKey, PhoneNumberAsText);
end;

local procedure GetPhoneNumber(var Setup: Record Setup; PhoneNumber: Text): Text
begin
    if Setup."Application State" <> Enum::"Application State"::Production then
        exit(Setup."Phone Number Test");
    exit(PhoneNumber);
end;

Previously, I would simply have made a Setup.Get() at the bottom level where I needed the information. This new approach forces me to have a well-organized architecture of my code.

Testing in the context of a production environment

[Test]
internal procedure TestEncodePhoneNumberProduction()
var
    TempSetup: Record Setup temporary;
    Decoders: Codeunit Decoders;
    Encoders: Codeunit Encoders;
    Object: JsonObject;
    CalculatedPhoneNumber: Text;
    CustomerPhoneNumber: Text;
begin
    // [SCENARIO #015] Testing encoding a phone number to a JSON object in a production environment.
    // [GIVEN] A phone number
    // [WHEN] encoded to JSON object
    // [THEN] we should get the same phone number

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup."Application State" := Enum::"Application State"::Production;
    CustomerPhoneNumber := '1234567890';
    Encoders.EncodePhoneNumber(TempSetup, 'Test', CustomerPhoneNumber, Object);
    Decoders.DecodeText(Object, 'Test', CalculatedPhoneNumber);
    this.Assert.AreEqual(CustomerPhoneNumber, CalculatedPhoneNumber, 'In the production environment we expected to encode the customer phone number directly.');
end;

Testing in the context of a test environment

[Test]
internal procedure TestEncodePhoneNumberTest()
var
    TempSetup: Record Setup temporary;
    Decoders: Codeunit Decoders;
    Encoders: Codeunit Encoders;
    Object: JsonObject;
    CalculatedPhoneNumber: Text;
    CustomerPhoneNumber: Text;
begin
    // [SCENARIO #016] Testing encoding a phone number to a JSON object in a test environment.
    // [GIVEN] A phone number
    // [WHEN] encoded to JSON object
    // [THEN] we should get the test phone number

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup."Application State" := Enum::"Application State"::Test;
    TempSetup."Phone Number Test" := '1234567890';
    CustomerPhoneNumber := '0987654321';
    Encoders.EncodePhoneNumber(TempSetup, 'Test', CustomerPhoneNumber, Object);
    Decoders.DecodeText(Object, 'Test', CalculatedPhoneNumber);
    this.Assert.AreEqual(TempSetup."Phone Number Test", CalculatedPhoneNumber, 'In the test environment we expected to ignore the customer phone number and encode the test phone number from the setup.');
end;

Running the actual code

In the actual code, the Setup.Get() is executed once at the highest level. This also gives me a better understanding of all dependencies on the setup table in the code. That is, we do not retrieve the setup table in multiple places throughout the code. We get it once and pass it around by reference.

Conclusion

This new design has several advantages:

• Better performance: Fewer reads to the database.
• Fast, isolated tests: Run tests without database access using just temporary tables.
• Improved code overview: Dependencies are clear and easy to manage.

Overall, this approach leads to a better design, even though it is not entirely how we used to write code. It is essential for writing modern, maintainable, and high-performance AL test code.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL
• Part 8: There is a new sheriff in town

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a condition for writing good tests, but it does not guarantee code coverage by tests.

Introduction

I will introduce three different contexts of Environment Interfaces. Discussed in parts 1, 2, and 3.

1. Interface against the system environment (Sandbox or Production)
2. Interface against an external API
3. Interface against the standard application

Environment interfaces usually have a single implementation within the application but can have several implementations in the test application. There is no corresponding Enum implementing the Interface.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Environment Interfaces are the solution to this apparent paradox.

Interface against Standard Business Central

In parts 1 and 2, we have seen how interfaces enable us to reach code we could otherwise never reach in tests.

However, there are other important constraints: we cannot spend too much time writing tests, and we only want to test our own code.

This is why we sometimes have to develop an interface against the standard application.

Finance interface

In this case, we are handling payments and refunds.

namespace MicrosoftPartner.AppName.Finance;

using Microsoft.Finance.GeneralLedger.Journal;
using Microsoft.Sales.History;

interface IFinance
{
    procedure CreatePaymentLine(
        var PaymentRequest: Record "Payment Request";
        var Setup: Record Setup;
        var GenJournalBatch: Record "Gen. Journal Batch";
        var GenJournalLine: Record "Gen. Journal Line";
        var GenJournalTemplate: Record "Gen. Journal Template";
        var PostedSalesInvoiceHeader: Record "Sales Invoice Header")

    procedure CreateRefundLine(
        var RefundRequest: Record "Refund Request";
        var Setup: Record Setup;
        var GenJournalBatch: Record "Gen. Journal Batch";
        var GenJournalLine: Record "Gen. Journal Line";
        var GenJournalTemplate: Record "Gen. Journal Template";
        var SalesCrMemoHeader: Record "Sales Cr.Memo Header")
}

Implementing the App version of the interface

The implementation is as you would expect. It is the code you would normally have written. We are inserting a GenJournalLine and we are using .Validate to ensure that the line is created with all the logic on the fields

codeunit 50019 "App Finance" implements IFinance
{
    procedure CreatePaymentLine(...)
    begin
        GenJournalLine.Init();
        GenJournalLine.Validate("Journal Template Name", GenJournalTemplate.Name);
        GenJournalLine.Validate("Journal Batch Name", GenJournalBatch.Name);
        GenJournalLine.Validate("Document Type", Enum::"Gen. Journal Document Type"::Payment);
        GenJournalLine.Validate("Document No.", PaymentRequest."Request Reference");
        
        ...
        GenJournalLine.Insert(true);
    end;

    procedure CreateRefundLine(...)
    begin
        GenJournalLine.Init();
        ...
        GenJournalLine.Insert(true);
    end;
}

Implementing the Test App version of the interface

This is where it becomes interesting.

Stub Finance

The stub function simply returns what I have asked it to return. This is how I control which part of my code is touched.

namespace MicrosoftPartner.AppName.Test.Helpers;

using Microsoft.Finance.GeneralLedger.Journal;
using Microsoft.Sales.History;

codeunit 50120 "Stub Finance" implements IFinance
{
    Description = 'Stub Finance';

    var
        SetupVar: Record Setup;
        GenJournalBatchVar: Record "Gen. Journal Batch";
        GenJournalLineVar: Record "Gen. Journal Line";
        GenJournalTemplateVar: Record "Gen. Journal Template";
        PaymentRequestVar: Record "Payment Request";
        RefundRequestVar: Record "Refund Request";
        PostedSalesCrMemoHeaderVar: Record "Sales Cr.Memo Header";
        PostedSalesInvoiceHeaderVar: Record "Sales Invoice Header";

    internal procedure CreatePaymentLine(var PaymentRequest: Record "Payment Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var PostedSalesInvoiceHeader: Record "Sales Invoice Header")
    begin
        PaymentRequest := this.PaymentRequestVar;
        Setup := this.SetupVar;
        GenJournalBatch := this.GenJournalBatchVar;
        GenJournalLine := this.GenJournalLineVar;
        GenJournalTemplate := this.GenJournalTemplateVar;
        PostedSalesInvoiceHeader := this.PostedSalesInvoiceHeaderVar;
    end;

    internal procedure SetupPaymentResponse(var PaymentRequest: Record "Payment Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var PostedSalesInvoiceHeader: Record "Sales Invoice Header")
    begin
        this.PaymentRequestVar := PaymentRequest;
        this.SetupVar := Setup;
        this.GenJournalBatchVar := GenJournalBatch;
        this.GenJournalLineVar := GenJournalLine;
        this.GenJournalTemplateVar := GenJournalTemplate;
        this.PostedSalesInvoiceHeaderVar := PostedSalesInvoiceHeader;
    end;

    internal procedure CreateRefundLine(var RefundRequest: Record "Refund Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var SalesCrMemoHeader: Record "Sales Cr.Memo Header")
    begin
        RefundRequest := this.RefundRequestVar;
        Setup := this.SetupVar;
        GenJournalBatch := this.GenJournalBatchVar;
        GenJournalLine := this.GenJournalLineVar;
        GenJournalTemplate := this.GenJournalTemplateVar;
        SalesCrMemoHeader := this.PostedSalesCrMemoHeaderVar;
    end;

    internal procedure SetupRefundResponse(var RefundRequest: Record "Refund Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var SalesCrMemoHeader: Record "Sales Cr.Memo Header")
    begin
        this.RefundRequestVar := RefundRequest;
        this.SetupVar := Setup;
        this.GenJournalBatchVar := GenJournalBatch;
        this.GenJournalLineVar := GenJournalLine;
        this.GenJournalTemplateVar := GenJournalTemplate;
        this.PostedSalesCrMemoHeaderVar := SalesCrMemoHeader;
    end;
}

Conclusion

Running logic in the base application introduces several challenges:

Setting up tests is time-consuming due to dependencies on G/L Accounts, Banks, General Journal Batch, General Journal Template, Number Series, and more — a rabbit hole that can consume significant amounts of time.

It creates a strong dependency on the base app, increasing maintenance overhead.

It is slow, as it writes to the database and rolls back changes, preventing the use of temporary variables.

By using Environment Interfaces, I have avoided these issues. My tests are fast, independent, and focused on my code.

You might say that this is cheating. That I am not really testing the code. And you are right in the sense that I have to understand perfectly what Business Central is returning when it creates the General Journal Line. But I am not testing that Business Central is working; I am testing that my code is working.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL
• Part 8: There is a new sheriff in town

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

London Style Terminology

When writing tests in Business Central, you may come across different types of test doubles—objects that replace real dependencies in your code. The “London style” (or “mockist”) terminology is widely used in the testing community to describe these patterns. Understanding these terms will help you communicate more clearly about your test design and choose the right approach for your scenario.

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a condition for writing good tests, but it does not guarantee code coverage by tests.

Introduction

I will introduce three different contexts of Environment Interfaces. Discussed in parts 1, 2, and 3.

1. Interface against the system environment (Sandbox or Production)
2. Interface against an external API
3. Interface against the standard application

Environment interfaces usually have a single implementation within the application but can have several implementations in the test application. There is no corresponding Enum implementing the Interface.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Environment Interfaces are the solution to this apparent paradox.

Interface against the external API

Before describing the interface, I need a small helper Enum.

Api Method Enum

There is a standard Enum, but I just want to keep it simple and to what I need.

enum 50005 "Api Method"
{
    value(0; GET)
    {
        Caption = 'GET', Locked = true;
    }
    value(1; POST)
    {
        Caption = 'POST', Locked = true;
    }
}

Api Request Interface

It is a very simple interface with just one function Send. But it is all we need.

interface IApiRequest
{
    procedure Send(RequestMethod: Enum "Api Method"; RequestUrl: Text; Payload: Text; SecretKey: SecretText; var ResponseStatusCode: Integer; var ResponseContent: Text)
}

Implementing the App version of the interface

The implementation of the Send function is quite generic and you can reuse this code. The API accepts a JSON payload, an encrypted key, and it returns a Status Code (200 for OK) and a response payload also in JSON.

codeunit 50011 "App Api Request" implements IApiRequest
{
    internal procedure Send(RequestMethod: Enum "Api Method"; RequestUrl: Text; Payload: Text; SecretKey: SecretText; var ResponseStatusCode: Integer; var ResponseContent: Text)
    var
        ApiTools: Codeunit ApiTools;
        HttpClient: HttpClient;
        HttpContent: HttpContent;
        ContentHeaders: HttpHeaders;
        RequestHeaders: HttpHeaders;
        HttpRequestMessage: HttpRequestMessage;
        HttpResponseMessage: HttpResponseMessage;
        Hash: SecretText;
    begin
        Hash := ApiTools.CreateHash(Payload, SecretKey);

        HttpRequestMessage.Method := Format(RequestMethod);
        HttpRequestMessage.SetRequestUri(RequestUrl);
        HttpRequestMessage.GetHeaders(RequestHeaders);
        RequestHeaders.Clear();
        RequestHeaders.Add('Accept', 'application/json');
        RequestHeaders.Add('Authorization', Hash);

        if RequestMethod = Enum::"Api Method"::POST then begin
            HttpContent.WriteFrom(Payload);
            HttpContent.GetHeaders(ContentHeaders);
            ContentHeaders.Clear();
            ContentHeaders.Add('Content-Type', 'application/json');
            HttpRequestMessage.Content := HttpContent;
        end;

        if HttpClient.Send(HttpRequestMessage, HttpResponseMessage) then begin
            ResponseStatusCode := HttpResponseMessage.HttpStatusCode();
            if ResponseStatusCode = ApiTools.HttpStatusCodeOK() then
                HttpResponseMessage.Content().ReadAs(ResponseContent)
            else
                ApiTools.WebServiceCallFailedError(HttpResponseMessage.HttpStatusCode());
        end else
            ApiTools.ConnectionError();
    end;
}

Implementing the Test App version of the interface

This is where it becomes interesting.

Stub Api Request

The stub function simply returns what I have asked it to return. This is how I control which part of my code is touched.

codeunit 50113 "Stub Api Request" implements IApiRequest
{
    Description = 'Stub Api Request';

    var
        ResponseStatusCodeVar: Integer;
        ResponseContentVar: Text;

    internal procedure Send(RequestMethod: Enum "Api Method"; RequestUrl: Text; Payload: Text; SecretKey: SecretText; var ResponseStatusCode: Integer; var ResponseContent: Text)
    begin
        ResponseStatusCode := this.ResponseStatusCodeVar;
        ResponseContent := this.ResponseContentVar;
    end;

    internal procedure SetupResponse(ResponseStatusCode: Integer; ResponseContent: Text)
    begin
        this.ResponseStatusCodeVar := ResponseStatusCode;
        this.ResponseContentVar := ResponseContent;
    end;
}

Using it

For each endpoint the API exposes, I have written a Codeunit with these functions

codeunit 50007 "Api Operation <Endpointname>"
{
    Description = 'Implementation of the Api Operation <Endpointname>';

    internal procedure OperationType(): Text
    begin
        exit('<Endpointname>');
    end;

    internal procedure RequestMethod(): Enum "Api Method"
    begin
        exit(Enum::"Api Method"::POST);
    end;

    internal procedure RequestPayload(var EndpointTable: Record "Endpoint Table Name"): Text[2048]
    begin
        exit(<the calculated payload>);
    end;

    internal procedure SendRequest(var Setup: Record Setup"; var EndpointTable: Record "Endpoint Table Name"; ApiRequest: Interface IApiRequest)
    var
        Decoders: Codeunit Decoders;
        ResponseStatusCode: Integer;
        SecretKey: SecretText;
        RequestUrl: Text;
        ResponseContent: Text;
    begin
        RequestUrl := Setup.ApiUrl(this.OperationType());
        SecretKey := Setup.ApiHmac();
        ResponseStatusCode := 0;
        ApiRequest.Send(this.RequestMethod(), RequestUrl, this.RequestPayload(EndpointTable), SecretKey, ResponseStatusCode, ResponseContent);
        Decoders.DecodeEndpointResponse(Setup, ResponseStatusCode, ResponseContent, EndpointTable);
    end;
}

Running the actual code

When I call the SendRequest function, I pass it the implementation.

var
  AppApiRequest: Codeunit "App Api Request";
...

ApiOperationEndpoint.SendRequest(Setup, Rec, AppApiRequest);

Testing in the context of a fake API

Before calling SendRequest, I call the SetupResponse and tell my fake API what to return to me. I know that this sounds strange at first, but trust me. I am not testing if the API works. I am testing how my code reacts to the response from the API. In this way, I can ensure that I am also testing more exotic events and responses.

This is the setup for success:

StubApiRequest.SetupResponse(200, '{"Result":"OK","Reference":"TEST"}');
ApiOperationEndpoint.SendRequest(TempSetup, TempRecord, StubApiRequest);

Failure could look like this:

StubApiRequest.SetupResponse(200, StubApiResponses.NotUniqueErrorResponse());
ApiOperationEndpoint.SendRequest(TempSetup, TempRecord, StubApiRequest);

I still get a valid JSON, but something is wrong. Then I am testing if my decoders are working as they should.

Conclusion

By using stubs and environment interfaces, I can thoroughly test all my decoding logic, failure detection, and error handling — without ever calling the real API during tests.

This approach ensures that every line of my code is exercised and verified, resulting in fast, reliable, and maintainable tests for my Business Central app.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL
• Part 8: There is a new sheriff in town

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

London Style Terminology

When writing tests in Business Central, you may come across different types of test doubles—objects that replace real dependencies in your code. The “London style” (or “mockist”) terminology is widely used in the testing community to describe these patterns. Understanding these terms will help you communicate more clearly about your test design and choose the right approach for your scenario.

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a prerequisite for writing good tests, but it does not guarantee code coverage by tests.

Introduction

I will introduce three different contexts of Environment Interfaces, discussed in parts 1, 2, and 3.

1. Interface against the system environment (Sandbox or Production)
2. Interface against an external API
3. Interface against the standard application

Environment interfaces usually have a single implementation within the application but can have several implementations in the test application. There is no corresponding Enum implementing the Interface.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Environment Interfaces are the solution to this apparent paradox.

Interface against the system environment

You can find the code for this article on GitHub.

github.com/finnpedersenfrance/BC-Environment-Interfaces

System Environment Enum

First, we need a new Enum. If you are running BC in the cloud, there are only two options. You are either in a Sandbox or a Production environment.

enum 50004 "System Environment"
{
    value(0; " ")
    {
        Caption = ' ', Locked = true;
    }
    value(1; Sandbox)
    {
        Caption = 'Sandbox';
    }
    value(2; Production)
    {
        Caption = 'Production';
    }
}

Environment Interface

Then we need an interface.

The interface is the recipe for which functions need to be implemented.

interface IEnvironment
{
    /// <summary>
    /// Returns the state of the current system environment. That is either Production, Sandbox or empty.
    /// </summary>
    /// <param></param>
    /// <returns>System Environment</returns>
    procedure SystemEnvironment(): Enum "System Environment"

    /// <summary>
    /// Returns the name of the current company.
    /// </summary>
    /// <param></param>
    /// <returns>Company Name</returns>
    procedure ThisCompanyName(): Text[30]

    /// <summary>
    /// Returns the state of the current company. That is either Production or Evaluation.
    /// </summary>
    /// <param></param>
    /// <returns>False if Production Company. True if Evaluation Company.</returns>
    procedure IsEvaluationCompany(): Boolean
}

Implementing the App version of the interface

The implementation is as you would expect. It is the code you would normally have written.

codeunit 50010 "App Environment" implements IEnvironment
{
    internal procedure SystemEnvironment(): Enum "System Environment"
    var
        EnvironmentInformation: Codeunit System.Environment."Environment Information";
    begin
        if EnvironmentInformation.IsProduction() then
            exit(Enum::"System Environment"::Production);
        if EnvironmentInformation.IsSandbox() then
            exit(Enum::"System Environment"::Sandbox);
        exit(Enum::"System Environment"::" ");
    end;

    internal procedure ThisCompanyName(): Text[30]
    begin
        exit(CopyStr(CompanyName(), 1, 30));
    end;

    internal procedure IsEvaluationCompany(): Boolean
    var
        Company: Record System.Environment.Company;
    begin
        Company.Get(CompanyName());
        exit(Company."Evaluation Company");
    end;
}

This also allows us to replace the booleans with an enum, which is much nicer.

Notice that ThisCompanyName() also solves the CodeCop Warning AA0139 (overflow). CompanyName() returns a Text which causes an overflow warning when you assign it to a Company Name field of type Text[30]. With this interface function, I have solved this everywhere I needed to use CompanyName().

Implementing the Test App version of the interface

This is where it becomes interesting.

Stub Production

I have written a Stub Production implementation of the environment. This allows me to fool my code into believing that it is in production.

codeunit 50102 "Stub Production Environment" implements IEnvironment
{
    Description = 'Stub Production Environment';

    procedure SystemEnvironment(): Enum "System Environment"
    begin
        exit(Enum::"System Environment"::Production);
    end;

    procedure ThisCompanyName(): Text[30]
    begin
        exit('Production Company Name');
    end;

    procedure IsEvaluationCompany(): Boolean
    begin
        exit(false);
    end;
}

Take a minute to look at how elegantly this allows us to test our code as if we were live in a production environment.

Stub Test

And a Stub Test implementation of the environment.

codeunit 50103 "Stub Test Environment" implements IEnvironment
{
    Description = 'Stub Test Environment';

    procedure SystemEnvironment(): Enum "System Environment"
    begin
        exit(Enum::"System Environment"::Sandbox);
    end;

    procedure ThisCompanyName(): Text[30]
    begin
        exit('Test Company Name');
    end;

    procedure IsEvaluationCompany(): Boolean
    begin
        exit(true);
    end;
}

And now we are in an evaluation company in a sandbox.

Using it

It is crucial for my application code to know if the application is Production or in a Test setup. For this, I am using an enum Application State.

enum 50006 "Application State"
{
    Extensible = true;

    value(0; " ")
    {
        Caption = ' ', Locked = true;
    }
    value(1; Test)
    {
        Caption = 'Test';
    }
    value(2; Production)
    {
        Caption = 'Production';
    }
}

I have written a function to calculate the state of the application based on the environment and the setup. The functions are in my Setup table.

internal procedure ValidateApplicationState(Environment: Interface IEnvironment)
begin
    Rec."Application State" := this.ApplicationState(Rec, Environment);
end;

internal procedure ApplicationState(var Setup: Record Setup; Environment: Interface IEnvironment): Enum "Application State"
begin
    case true of
        (Setup.Licensee = Environment.ThisCompanyName()) and
        (Environment.SystemEnvironment() = Enum::"System Environment"::Production) and
        (not Environment.IsEvaluationCompany()):
            exit(Enum::"Application State"::Production);
        (Setup.Licensee = Environment.ThisCompanyName()):
            exit(Enum::"Application State"::Test);
        else
            exit(Enum::"Application State"::" ");
    end;
end;

We are in production mode, only and only if

• the app is in a Production environment and
• it is not an evaluation company, and
• the Licensee matches the name of the current company

We are in a test mode if

• the solution is running in a sandbox or
• the company is an evaluation company
• the Licensee still has to match the name of the current company

An important safety feature

If someone makes a copy of the company, the company name will differ from the Licensee name in our setup, which will automatically disable the solution and prevent anyone from using the solution by mistake.

Now I can call this function in both my tests and production, reaching all the code.

Testing in the context of a test environment

Testing that the application is in test mode in a sandbox.

[Test]
internal procedure TestTestMode()
var
    TempSetup: Record Setup temporary;
    StubTestEnvironment: Codeunit "Stub Test Environment";
begin
    // [SCENARIO #003] Application State in test
    // [GIVEN] a setup with a valid licensee
    // [WHEN] calling ValidateApplicationState
    // [THEN] the application state should be test

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup.Licensee := StubTestEnvironment.ThisCompanyName();
    TempSetup.ValidateApplicationState(StubTestEnvironment);

    this.Assert.AreEqual(Enum::"Application State"::Test, TempSetup."Application State", 'Expected Application State to be Test.');
end;

Testing in the context of a production environment

Testing in our simulated production environment.

[Test]
internal procedure TestProductionMode()
var
    TempSetup: Record Setup temporary;
    StubProductionEnvironment: Codeunit "Stub Production Environment";
begin
    // [SCENARIO #002] Application State in production
    // [GIVEN] a setup with a valid licensee
    // [WHEN] calling ValidateApplicationState
    // [THEN] the application state should be production

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup.Licensee := StubProductionEnvironment.ThisCompanyName();
    TempSetup.ValidateApplicationState(StubProductionEnvironment);

    this.Assert.AreEqual(Enum::"Application State"::Production, TempSetup."Application State", 'Expected Application State to be Production.');
end;

Testing that the solution is disabled if there is no licensee.

[Test]
internal procedure TestNoCompanyName()
var
    TempSetup: Record Setup temporary;
    StubProductionEnvironment: Codeunit "Stub Production Environment";
begin
    // [SCENARIO #001] No company name in disabled environment
    // [GIVEN] a setup with no licensee
    // [WHEN] calling ValidateApplicationState
    // [THEN] the application state should be empty. I.e. disabled.

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup.Licensee := '';
    TempSetup.ValidateApplicationState(StubProductionEnvironment);

    this.Assert.AreEqual(Enum::"Application State"::" ", TempSetup."Application State", 'Expected Application State to be disabled.');
end;

The code in the App

I am not testing the following code at the highest level. I call the function from the Setup page.

trigger OnModifyRecord(): Boolean
var
    AppEnvironment: Codeunit "App Environment";
begin
    Rec.ValidateApplicationState(AppEnvironment);
end;

Bonus Safety feature

You can implement one more safety feature. Just to be sure that you solution is disabled in the copied company. Subscribe to the OnAfterCopyCompanyOnAction event.

codeunit 50031 "Event Subscribers Copy Company"
{
    Description = 'Event Subscribers for Copy Company. This ensures that the copied company cannot be used by mistake.';

    [EventSubscriber(ObjectType::Page, Page::Companies, OnAfterCopyCompanyOnAction, '', false, false)]
    local procedure OnAfterCopyCompanyOnAction(CompanyName: Text[30])
    var
        Setup: Record Setup;
    begin
        Setup.ChangeCompany(CompanyName);
        if Setup.Get() then begin
            Setup.Licensee := '';
            Setup."Application State" := Enum::"Application State"::" ";
            Setup."Job Scheduler on Standby" := true;
            Setup.Modify(false);
        end;
    end;
}

Conclusion

Bugs are often found in code that was never executed before. Think about it. If I had a bug in the part of my code that would only be reached in production, I would otherwise never find it during tests.

With this design, I am quite confident that my code will act as planned when put in production and my tests cover 100% of my code.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL
• Part 8: There is a new sheriff in town

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

London Style Terminology

When writing tests in Business Central, you may come across different types of test doubles—objects that replace real dependencies in your code. The “London style” (or “mockist”) terminology is widely used in the testing community to describe these patterns. Understanding these terms will help you communicate more clearly about your test design and choose the right approach for your scenario.

I recently took a small detour from my usual topics to write my first Wikipedia article.

I have been renting out apartments in Denmark for more than 30 years and found myself searching for some information that dated back before 2001.

I wanted to share the information because

• It was hard to find
• It was of general interest for both parties when renting an apartment, a room, or a house in Denmark.
• It potentially concerns a lot of people. Basically, all landlords and tenants.

Since it was missing from Wikipedia, I decided to fill that gap. Here is a short guide, based on my experience, on how you can do it too.

My article (only in Danish)

• Wikipedia: Standardblanket for lejeaftaler

In short, the article helps landlords and tenants to use the right version of the rental contract. Over the past 29 years, there have been 4 versions, and I explain the importance of using the right version and the potential consequences when you don’t.

Preparation

Check if your topic is missing or underdeveloped

Before creating an article, do a quick search on Wikipedia to make sure it doesn’t already exist or that it’s not adequately covered.

Read the key guidelines

• Wikipedia:Neutral Point of View
• Wikipedia:Manual of Style
• Wikipedia:Five Pillars
• Wikipedia:Notability

There is a lot to read and it took me some time. Most is common sense, but I had extra focus on ensuring the Neutral Point of View. I also wanted to make sure that it looked like a real Wikipedia article. That is, ensure consistency.

Gather reliable sources

Every fact, statement, or claim should ideally have a reference from a reputable source. Wikipedia articles thrive on verifiability.

Most of my sources were government websites, so that was easy.

Writing Your Draft

Once you have signed up, you go to your Sandbox and start writing.

Use the Wikipedia Sandbox

You draft your article in the personal sandbox to get familiar with Wikipedia’s markup and style before publishing.

Focus on neutrality

Wikipedia articles must avoid personal opinions. State the facts, cite sources, and keep a neutral tone.

I made sure that both the landlord and the tenant would benefit equally from the article.

Wikipedia markup

Wikipedia has a special markup language, which is different from, for example, Markdown. But you don’t really have to know anything about it. Simply use the editor.

Here are a few examples.

• Use double square brackets for internal links, e.g., [[Article Title]].
• Bold the article title the first time it appears, e.g., '''Article Title'''.
• Use == Heading == syntax for section titles.

Publishing and Follow-Up

Once you have moved your article from the Sandbox to its real place, it is no longer your baby. It lives its own life, and other people can contribute to it.

Review your draft

Double-check grammar, style, and references. Ensure your draft aligns with Wikipedia’s Manual of Style.

Move from sandbox to main space

Once you’re confident, you can publish your draft. Be prepared for feedback and possible edits from the Wikipedia community.

Monitor and respond

Other editors may add, remove, or refine content. Engage politely on the article’s talk page if you need to discuss changes.

Why Contribute?

Share knowledge

If you notice a topic of general interest that isn’t on Wikipedia or is incomplete, adding your expertise benefits everyone.

Strengthen Wikipedia

By contributing high-quality articles, you help maintain and improve the world’s largest encyclopedia.

Learn along the way

Writing in Wikipedia’s style forces you to be concise, neutral, and well-referenced — excellent skills for any research-based writing.

Closing Thoughts

Contributing to Wikipedia was hard work, fun, rewarding, and informative.

In The Divine Comedy by Dante Alighieri, in part Purgatorio, Canto XV (15), Virgil explains to Dante:

That the more of any material thing one man has, the less of it there is for others; whereas the more peace or knowledge or love one man has, the more there is for all the others.

Happy editing!