I’ve written an extension for VS Code to help run your AL tests in local Docker containers. Search for “AL Test Runner” in the extension marketplace or click here. Feedback, bugs, feature suggestions all gratefully received on the GitHub repo or email@example.com
As soon as Freddy added capability to the navcontainerhelper module to execute automated tests I was excited about the potential for:
- Making test execution in our build pipeline simpler and more reliable
- Running tests from Visual Studio Code as part while developing
I’ve written about both aspects in the past, but especially #1 recently – about incorporating automated tests into your Azure DevOps pipeline.
This post is about #2 – incorporating running tests as early as possible into your development cycle.
Finding Bugs ASAP
You’ve probably heard the idea – and it’s common sense even if you haven’t – that the cost of finding a bug in your software increases the later in the development/deployment cycle you find it.
If you realise you made a silly mistake in code that you wrote 2 minutes ago – there’s likely no harm done. Realise there is a bug in software that is now live in customers’ databases and the implications could be much greater. Potentially annoyed customers, data that now needs fixing, support cases, having to rush out a hotfix etc.
We’ve all been there. It’s not a nice place to visit. I once deleted all the (hundreds of thousands of) records in the Purch. Rcpt. Line table with a Rec.DELETEALL on a temporary table…turns out it wasn’t temporary…and I was working in the live database.
Writing automated tests can help catch problems before you release them out into the wild. They force you to think about the expected behaviour of the code and then test whether it actually behaves like that. Hopefully if the code that we push to a branch in Azure DevOps has a bug it will cause a test to fail, the artifacts won’t be published, the developer will get an email and the customer won’t be the hapless recipient of our mistake. No harm done.
However, the rising cost of finding a bug over time still applies. Especially if the developer has started working on something else or gone home. Getting back your head back into the code, reproducing and finding the bug and fixing it are harder if you’ve had a break from the code than if you went looking for it straight away.
Running Tests from VS Code
That’s why I’m keen that we run tests from VS Code as we are writing them. Write a test, see it fail, write the code, see the test pass, repeat.
I’ve written about this before. You can use tasks in VS Code to execute the required PowerShell to run the tests. The task gives you access to the current file and line no. so that you can fancy stuff like running only the current test or test codeunit.
AL Test Runner
However, I was keen to improve on this and so have started work on a VS Code extension – AL Test Runner.
The goals are to:
- Make it as simple as possible to run the current test, tests in the current codeunit or all tests in the extension with commands and keyboard shortcuts
- Cache the test results
- Decorate test methods according to the latest test results – pass, fail or untested
- Provide extra details e.g. error message and callstack when hovering over the test name
- Add a snippet to make it easier to create new tests with placeholders for GIVEN, WHEN and THEN statements
Important: this is for running tests with the navcontainerhelper PowerShell module against a local Docker container. Please make sure that you are using the latest version of navcontainerhelper.
- Download the extension from the extension marketplace in VS Code and reload the window.
- Open a folder containing an AL project
- Open a test codeunit, you should notice that the names of test methods are decorated with an amber background (as there are no results available for those tests)
- The colours for passing, failing and untested tests are configurable if you don’t like them or they don’t fit with your VS Code theme. Alternatively you can turn test decoration off altogether if you don’t like it
- Place the cursor in a test method and run the “AL Test Runner: Run Current Test” command (Ctrl+Alt+T)
- You should be prompted to select a debug configuration (from launch.json), company name, test suite name and credentials as appropriate (depends if you’re running BC14 or BC15, if you have multiple companies, authentication type etc.)
- I’ve noticed that sometimes the output isn’t displayed in the new terminal when it is first created – I don’t know why. Subsequent commands always seem to show up fine 🤷♂️
- Use the “ttestprocedure” to create new test methods
If you’re using Git then I’d recommend adding the .altestrunner folder to your .gitignore file:
Committing the config file and the test results xml files doesn’t feel like a great idea.
15 thoughts on “AL Test Runner for Visual Studio Code”
As always, great stuff. I will definitely use it and discontinue our own scripts.
It seems that always, when you run a Powershell script for the first time VS Code is started, it doesn’t show anything in the terminal. You can see the same behavior when you use a task that executes a Powershell script. Let’s hope that this will be fixed eventually.
Thanks Peter 👍
Nice to know that it’s not just me struggling with the missing output! It’d be good to have any feedback or suggestions when you try it out.
Receiving an error: ‘Invoke-ALTestRunner’ is not recognized as an internal or external command,
operable program or batch file.
Docker Container is on a server not my development machine is that an issue?
NavContainer-Helper version is 0.6.4.19
You do need to host the container on the machine that you are using VS Code on, yes.
Although, I don’t think that is the cause of the error. When do you get this error? When using the commands to run tests from VS Code?
The commands should open a new terminal in VS Code and import the ALTestRunner PowerShell module to run the tests (the tests are actually run by the navcontainerhelper module).
Yes, the error occurs when I attempt to run the test code unit or procedure from the VS Code Command Palette.
Currently we are using a server for the containers and using VS Code locally. Guess I won’t be able to use your tool at this time.
Really like the concept!