Another instalment of my musings on running automated tests for Microsoft Dynamics 365 Business Central from Visual Studio Code.
Objective
What are we up to this time? As a brief reminder, I’m trying to make it as easy as possible to run automated tests from Visual Studio Code. I figure the faster and simpler it is to publish your code changes and run the tests the more inclined you are going to be to do it. The more you test the better your code will be.
If you’re trying to follow a discipline like Test-Drive Development you need tight feedback loops writing code and running tests. Being able to do that from the IDE and without having to switch back and forth to the browser is so much nicer.
To that end, if you are working on a particular test codeunit maybe it makes sense to only run the tests in that codeunit – in the interests of getting the feedback from those tests as quickly as possible. Or maybe just running the single test method that you’re working on. Once, you’re happy with those changes you can run the whole test suite again to make sure you haven’t broken anything else in the meantime.
Fortunately, it turns out we’ve already got the pieces we need to assemble this jigsaw.
NavContainerHelper
Being the considerate sort of chap that he is, Freddy has already included testCodeunit and testFunction parameters for the Run-TestsInNavContainer function. We just need to figure out how to plug the right values into those parameters.
Some More About VS Code Tasks
In this post I showed how you can define a task in VS Code to run some PowerShell. It turns out you can do more in tasks.json than I realised.
This is what my file looks like now:
{
// 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-TestsFromVSCode -CurrentFile ${file} -CurrentLine ${lineNumber}",
"group": {
"kind": "test",
"isDefault": true
},
"presentation": {
"echo": true,
"reveal": "always",
"focus": false,
"panel": "shared",
"showReuseMessage": true,
"clear": true
}
}
]
}
The presentation object controls the behaviour of the terminal that the task is run in. I’m just using it to clear the terminal each time.
The really interesting part is ${file} and ${lineNumber}. These placeholders are replaced with the current file and current line number in the editor when the task is executed. Ooooo. You can probably see where I’m going with this. That’s all the information we need to run the current test codeunit and method.
I’ve created a new Run-TestsFromVSCode function in our PowerShell module to handle this. Notice I’m calling that function from the task now instead of our Run-BCTests function directly.
Run-TestsFromVSCode
Assuming a file path has been passed to the function it determines whether the current file is a test codeunit i.e. does it contain the text “Subtype = Test”? If so, use Regex to find the id of the codeunit from the first line.
Now attempt to find the previous declaration of a test function from the current line no (search backwards for a line that contains “[Test]” then forwards from that line to a procedure declaration).
Then call Run-BCTests with all the information that you’ve been able to find. Passing an asterisk rather than blank for the codeunit and/or method acts as a wildcard and will run everything, instead of nothing.
function Run-TestsFromVSCode {
param(
# The current file the tests are invoked from
[Parameter(Mandatory=$false)]
[string]
$CurrentFile,
# The current line no. in the current file
[Parameter(Mandatory=$false)]
[string]
$CurrentLine
)
if ($null -eq $CurrentFile) {
Run-BCTests
}
else {
# determine if the current file is a test codeunit
if ((Get-Content $CurrentFile -Raw).Contains('Subtype = Test')) {
$TestCodeunit = [Regex]::Match((Get-Content $CurrentFile).Item(0),' \d+ ').Value.Trim()
if ($null -ne $CurrentLine) {
$Method = Get-TestFromLine -Path $CurrentFile -LineNumber $CurrentLine
if ($null -ne $Method) {
Run-BCTests -TestCodeunit $TestCodeunit -TestMethod $Method
}
else {
Run-BCTests -TestCodeunit $TestCodeunit -TestMethod '*'
}
}
}
else {
Run-BCTests
}
}
}
function Get-TestFromLine {
param (
# file path to search
[Parameter(Mandatory=$true)]
[string]
$Path,
# line number to start at
[Parameter(Mandatory=$true)]
[int]
$LineNumber
)
$Lines = Get-Content $Path
for ($i = ($LineNumber - 1); $i -ge 0; $i--) {
if ($Lines.Item($i).Contains('[Test]')) {
# search forwards for the procedure declaration (it might not be the following line)
for ($j = $i; $j -le $Lines.Count; $j++)
{
if ($Lines.Item($j).Contains('procedure')) {
$ProcDeclaration = $Lines.Item($j)
$ProcDeclaration = $ProcDeclaration.Substring($ProcDeclaration.IndexOf('procedure') + 10)
$ProcDeclaration = $ProcDeclaration.Substring(0,$ProcDeclaration.IndexOf('('))
return $ProcDeclaration
}
}
}
}
}
Export-ModuleMember -Function Run-TestsFromVSCode
The terminal output from the task now looks like this:
Notice the current file and line number passed to the task and the current codeunit id and method passed to navcontainerhelper to run.
To run all the methods in the current codeunit move the cursor above the line of the first test method declaration.
To run all methods in all codeunits move the cursor outside a test codeunit – although you must have some file open otherwise VS Code will fail to resolve the ${file} and ${lineNumber} placeholders.
You could of course define more tasks to run these options if you prefer.
Conclusion
All of this enables this kind of workflow, if that’s what you’re into:
- Create a new (failing) test and publish app
- Run (just) that test and check that it fails
- Write production code and publish app
- Run (just) that test and check that it now passes
- Run all the tests in that codeunit / your whole suite
- Commit your changes
Wish List
I’m pleased with how far I’ve been able to get, but there’s still some significant items not crossed off the wish list.
Debugging Tests
For now you still have to launch the browser (at least we can debug without publishing these days) and start the test from that session. I believe the old “debug next” functionality we used to have in the Windows client debugger is on the roadmap somewhere. That would do the trick.
Performance
Leaves a lot to be desired. Running a single method in a single test codeunit takes anywhere between 6 and 10 seconds. Obviously, some of that time is the test itself and is in our control, but most of that is preparing the suite and creating and connecting the client.
I know Microsoft are overhauling how tests are executed by the platform, so maybe some performance gains are also in the pipeline.
James Pearson 