Execute your Microsoft Dynamics 365 Business Central tests – with a keyboard shortcut – without leaving the comfort of your favourite IDE. What’s not to love?
Background
We’ve come a long way with testing our apps in Microsoft Dynamics 365 Business Central / NAV. By “we” I mean our internal development practices but also the capabilities of the platform.
- We didn’t have any automated testing – we had a joke written on the white board in the development office, “F11 is testing”
- Microsoft made it possible to create and run automated tests in Dynamics NAV – we didn’t use it
- Microsoft improved the tooling with the release of the “Test Tool” page
- We started to experiment with it and to write our own tests
- We picked up the idea of automating test runs with a build pipeline…
…and that was a bit of a problem. The best way to run the tests was through the Windows client. That meant using the dynamicsnav:// protocol to open the client, creating a ClientUserSettings.config file, ending the client process when it had finished…a big improvement on not testing at all – but hardly elegant.
With Microsoft’s adoption of Docker to distribute NAV / Business Central images came Freddy’s navcontainerhelper PowerShell module. A big, and relatively recent, step forward was the ability to run a test suite in a Docker container from PowerShell.
If you don’t know I’m talking about you’re best heading over to Freddy’s blog and doing some background reading.
Running the Tests
This is all great for our build process. We can create a Docker container, install the app(s), prepare the test suite (see here), run the tests from PowerShell, upload the results and bin the container.
As soon as the ability to run tests from PowerShell became available I was interested in how we could use them in our everyday development, not just in the pipeline. If you do any reading about Test Driven Development you’ll find that it is based on a very tight feedback loop. Write a test, write a small chunk of production code, run the tests. Repeat.
I want to be able to run the tests from the same environment that I write the code – Visual Studio Code. I don’t want to be switching back and forth from VS Code to the browser, refreshing test codeunits or methods and running them there. I just don’t find it a nice way to work.
With VS Code’s built in terminal and navcontainerhelper loaded you don’t have to.
- Set “launchBrowser” to false in launch.json
- Write a test
- Execute Run-TestsInNavContainer in the terminal and review the results
- Write some production code
- Publish without debugging
- Execute Run-TestsInNavContainer in the terminal and review the results
- Repeat steps 2-5
I actually use Run-BCTests, a function in our own PowerShell module. Run-BCTests is a wrapper for Run-TestsInNavContainer which:
- Reads the name of the container from launch.json (see below) – unless a different container is specified
- Creates a PowerShell credential object from the credentials we store in a json file in the repo
- Optionally downloads our “Build Helper” app (from its last successful build – like this) to load our test codeunits and methods into the DEFAULT suite
- Use Run-TestsInNavContainer to run the tests and output the results to the terminal
Get-ContainerFromLaunchJson
You already have to set the name of your container in the launch.json file to publish your app, so why not read it from there rather than typing your container name all the time?
function Get-ContainerFromLaunchJson {
param (
# Path to launch.json
[Parameter(Mandatory=$false)]
[string]
$LaunchJsonPath = (Join-Path (Get-Location) '.vscode\launch.json')
)
if (!(Test-Path $LaunchJsonPath)) {
return ''
}
$LaunchJson = ConvertFrom-Json (Get-Content $LaunchJsonPath -Raw)
if ($LaunchJson.configurations.Count -ne 1) {
return ''
}
else {
$Container = $LaunchJson.configurations.Item(0).server
$Container = $Container.Substring($Container.IndexOf('//') + 2)
$Container
}
}
Note that the container name in launch.json will need to match the case of the Docker container name. For reasons best known to Docker container names are case-sensitive.
VS Code Tasks: Running Tests With a Keyboard Shortcut
In pursuit of making it as quick and easy as possible to execute the tests from VS Code we can go a step further and create a VS Code task.
Create a tasks.json file in the .vscode folder. Mine looks like this:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "Run BC Tests",
"type": "shell",
"command": "Run-BCTests -DoNotPrepTestSuite",
"group": {
"kind": "test",
"isDefault": true
}
}
]
}
This defines a task with the label “Run BC Tests” which runs the command “Run-BCTests -DoNotPrepTestSuite” (the PowerShell function described above). It is set as the default task in the test group.
This allows you to run “Run Test Task” from the command palette.
Now you can assign a keyboard shortcut to that command. Open “Preferences: Open Keyboard Shortcuts” from the command palette and search for “Run Test Task”.
Double click that entry to set whatever keyboard combination you like. I’ve opted for ctrl+shift+T.
Conclusion
This takes us a step closer to having a code-and-test-in-the-IDE development experience and allows this kind of tight test/production code iteration without having to open the browser:
- Write some test code
- Publish without debugging (Ctrl+F5)
- Run the tests (Ctrl+Shift+T) and check that they fail
- Write production code
- Publish without debugging (Ctrl+F5)
- Run the tests (Ctrl+Shift+T) and check that they pass
- Repeat
Of course, this does not remove the need to open the browser, check the look and feel and test your code manually at some point but it does go some way to alleviating the pain of publishing and executing the tests in the browser.
Future
I like it, but it’s still a little clunky. For one, it runs too slowly – the gif at the head of this post is real-time. Also, you still have to populate the test suite with the test codeunits and methods that you want to run at some point. Our PowerShell module can do that, but it’s another manual step to run.
There’s only so much we can do about these issues until Microsoft overhaul the whole testing framework – which I understand they are working on. In the meantime, here’s some other ideas that we haven’t implemented yet.
- Use the previous commit, or uncommitted changes to determine the test codeunit(s) to run. Run-TestsInNavContainer has optional parameters to specify what to run
- Filter the results so that you are only notified of failures instead of having to pick them out of the successes
- Work some magic in VS Code to have the test task automatically triggered when the app is published to the server
James Pearson 