Let’s work together
Want to discuss potential opportunities? Pick the most suitable way to contact us.
Book a call+370 5 2 780 400
info@ba.lt
Unit testing is a cornerstone of modern software development – especially when following Test-Driven Development (TDD) practices. But for developers working with Progress OpenEdge ABL, setting up and running tests has not always been straightforward. That is where the ABLUnit Test Runner extension for Visual Studio Code steps in.
In this blog post, we will explore how this open-source extension simplifies ABL unit testing by integrating directly with VS Code’s built-in testing tools. You will learn what ABLUnit is, how the extension works, the types of configurations it supports, and the real-world benefits we have experienced using it in a complex ERP project. We will also walk through common pitfalls and how to troubleshoot them effectively.
Whether you are new to ABL unit testing or looking to improve your existing workflow, this guide will help you get started with confidence.
Before diving deeper into the extension, it is worth understanding what ABLUnit itself is.
ABLUnit is the officially supported unit testing framework for OpenEdge ABL. It is patterned after well-known xUnit-style frameworks such as JUnit (Java), NUnit (.NET), and PyTest (Python), bringing structure and automation to ABL testing that was, until relatively recently, less formalised.
According to Progress documentation, ABLUnit provides:
Essentially, it gives you everything you need to practice Test-Driven Development or simply write regression tests as part of a maintainable codebase.
We were working on a project which involved creating an ERP system for the client. As a team, we were responsible for building both the front-end and back-end of the system. For testing the business logic layer, we adopted their suggestion to use the ABLUnit Test Runner extension. This tool offers a simple and efficient way to execute unit tests, enabling us to integrate automated testing into our development process and confidently move toward Test-Driven Development practices: writing tests first, then building the code to fulfil them.
Not sure how this could benefit your business? Talk to our team of Progress OpenEdge experts to discover the possibilities.
Since the extension integrates tightly with the native VS Code testing framework, it is worth familiarising yourself with VS Code’s Testing Documentation, especially if you’re new to its test interface or workflows.
The extension itself is quite simple. The diagram below illustrates the flow of inputs and outputs within the extension.
The extension functions by consuming input in the form of tested ABL files (either classes or procedures) along with optional configuration files. Here is a breakdown of its core components:
To run ABLUnit tests in Visual Studio Code, simply use the built-in Test Explorer panel:
3. To run tests in a specific folder, use the play icon next to that folder or test suite:
The results of executed ABLUnit tests are captured in the results.xml file – a machine-readable file used by the extension’s Testing panel to display test outcomes, such as coloured pass/fail indicators, skipped status (for example, the Test.cls suite represents a test that was not run), and coverage metrics that assist in refactoring and fixing code. Test results are organised by workspace folder, directory, class, and individual test methods. Additionally, the execution time for each test and group is displayed, making it easier to evaluate overall test performance.
Here are some notable challenges we encountered using this tool:
When running tests, a warning appears stating that configurations are optional. This is generally not an issue (most tested workspaces operate without any configuration) but for complex setups, defining a custom profile in .vscode/ablunit-test-profile.json can help resolve any anomalies.
Sometimes, when the source code changes, the tests do not pick up the latest version. This can happen due to stale rcode (compiled output). Restarting the ABL language server through the VS Code command palette usually resolves this, ensuring the tests use the most current code. A future version of the extension may emit a warning when rcode is older than the source to help catch this earlier: Issue #306
Errors like the following may occur:
Error parsing results ...\results.xml. err=EntryNotFound (FileSystemError): Error: ENOENT: no such file or directory, open '...\results.xml'
This typically happens when the project is opened as a folder instead of a workspace. The solution is to always open your project as a workspace. Having a workspace is the expected mode of operation for the extension.
Another common error relates to the database used in tests not being found. While the extension attempts to provide diagnostic feedback, in these cases, manually verifying database access and configurations is often necessary.
If your tests rely on a database and it is not properly connected or configured, you will likely see vague or misleading test errors, or an error such as the above.
In recent updates, more helpful diagnostics are being added to handle common issues like missing or misconfigured database connections. You can follow progress and improvements here: PR #307 – Improve feedback for DB connection issues
The use of this extension significantly enhanced our unit testing process.
By incorporating the ABLUnit Test Runner extension into our development environment, we were able to:
Encouraged by its success, we have continued using the ABLUnit Test Runner extension in other Progress ABL projects with similarly positive results. Its consistent performance and seamless integration with our preferred IDE have made it an invaluable tool in our development toolkit.
Would you like to know more about how it can benefit your business? Do not hesitate to speak to our team of Progress OpenEdge experts.
In our experience, the ABLUnit Test Runner extension is the most effective and streamlined way to run ABL unit tests when using Visual Studio Code.
Anyone interested in digging deeper (or even contributing) can find documentation, more examples, snippets and the source code itself on the extension’s GitHub repository: kenherring/ablunit-test-runner.
Want to discuss potential opportunities? Pick the most suitable way to contact us.
Book a call+370 5 2 780 400
info@ba.lt
Discover key lessons for junior developers from real Progress OpenEdge Academy graduates. Learn how hands-on experience, teamwork, and mindset shape a successful dev career.
Explore how SEPA and upcoming EU regulations make Verification of Payee (VoP) essential for secure, instant euro payments by October 2025.
Explore why financial transparency is key for crypto firms under MiCA regulations and how Lithuania supports smooth compliance by the end of 2025.