Dolt is a plug-in MySQL-compliant database that behaves like Git, allowing you to version control your data. In the last couple of months, I've experienced first-hand Dolt's suite of tens of thousands of tests that span the Golang testing framework to the Bash Automated Testing System (Bats) and more to ensure that correctness. We initially started using Bats to test Dolt's command-line but have since expanded its use into many areas, i.e., Dolt SQL Server MySQL Client Support, Dolt SQL Server Docker Image and Entrypoint, and other tools you can find in our Bats integration tests. In other words, Bats is a crucial part of our testing strategy, and with Dolt's open-source nature, we invite you to get started Contributing to Dolt and Testing Dolt using Bats.

Pause! Windows users, I may have gotten ahead of myself with the call-to-action. After all, the title is "Run Bats with a Single Click on Windows using GoLand". Unfortunately, Bats is a Unix-based testing framework, so Windows users may find it challenging to run tests out of the box. We covered this in the Testing Dolt using Bats blog above in more detail using Windows Subsystem for Linux (WSL) and some manual setup. However, I wanted to share my experience using GoLand, a Golang JetBrains IDE, with BashSupportPro, a paid plugin, to run Bats tests with the click of a button.

What is BashSupportPro?

BashSupportPro is available on the JetBrains marketplace and is a paid plugin that adds support for Bash and Zsh scripts on many levels. It includes syntax highlighting, code completion, inspections, refactorings, and more. It also supports Bats, which is the focus of this blog. To be clear, it's not a necessary plugin to run these Bats tests, but it does bring some convenient QOL features to the table.

The Good Ol' Days

Before I discovered BashSupportPro, I was using WSL2 with Ubuntu 22.04 LTS and a Git Bash, a terminal that comes with Git for Windows which provides enough Bash emulation to run Bats tests. Luckily, it was pretty straightforward to get started:

bats dolt/integration-tests/bats/ <test-file>.bats

This command alone runs the full suite of tests in the specified file. You can also filter specific tests using the -f flag, which becomes common place to avoid running the time-consuming suite of tests.

Context, I found myself switching between my IDE and terminal often, which was a bit of a drag. Furthermore, having to run the go install commands after each change to the codebase was a bit tedious. Not to mention having to filter specific tests using a custom -f flag when running bats. Coincidentally, our CI had similar griefs when it came to running all Bats at once too in terms of performance, so we came up with lambdabats: Running BATS Tests with Massive Parallelism. But our issue here is more about the developer experience, so what's a Windows user to do?

BashSupportPro to the Rescue

BashSupportPro mainly affects the IDE experience between Bash and Zsh related files. If you're familiar with the JetBrains IDE testing interface, it also in embeds itself here. After installing the plugin, you can open any .bats file, and you'll see a green play button next to each test case:

After clicking the play button, you'll see a new run configuration created in the top right corner of your IDE, which you can edit to your liking.

I've made some modifications for the next output to be more verbose and show the output of passing and failing tests. This also shows how the test name patterns are passed to the -f flag when running Bats. These are auto-generated based on the test case you clicked so no more manual filtering!

C:\windows\system32\wsl.exe bash -l /mnt/c/Users/Elian/AppData/Roaming/JetBrains/GoLand2025.2/plugins/bashsupport-pro/bats-core/bin/bats \
  -F bashpro -f ^diff:[[:space:]]+db[[:space:]]+collation[[:space:]]+diff$ -r --verbose-run \
  --show-output-of-passing-tests --print-output-on-failure \
  /mnt/c/Users/Elian/dolt_workspace/dolt/integration-tests/bats/diff.bats
Testing started at 2:01 PM ...
1..1

# Successfully initialized dolt data repository.

# diff --dolt a/__DATABASE__colldb b/__DATABASE__colldb

# --- a/__DATABASE__colldb

# +++ b/__DATABASE__colldb

# +CREATE DATABASE `colldb` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_spanish_ci */;

# diff --dolt a/__DATABASE__colldb b/__DATABASE__colldb

# --- a/__DATABASE__colldb

# +++ b/__DATABASE__colldb

# diff --dolt a/__DATABASE__colldb b/__DATABASE__colldb

# --- a/__DATABASE__colldb

# +++ b/__DATABASE__colldb

# +CREATE DATABASE `colldb` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_spanish_ci */;

# {"tables":[{"name":"__DATABASE__colldb","schema_diff":["ALTER DATABASE `colldb` COLLATE='utf8mb4_spanish_ci';"],
# "data_diff":[]}]}

# ALTER DATABASE `colldb` COLLATE='utf8mb4_spanish_ci';

# dolt version 1.59.17

# Warning: you are on an old version of Dolt. The newest version is 1.59.18.

# To disable this warning, run 'dolt config --global --add versioncheck.disabled true'

# feature version: 7

You can see above what I meant by the plugin not being necessary. In reality, WSL is doing the heavy lifting here, running the Bats tests, but the command generation and run configuration is handled by the plugin.

Before Launch Build dolt

You may have noticed my Before Launch section has an extra step that runs before the Bats test. GoLand supports tasks that you can launch before launch of a selected run/debug config. I've used it here to resolve our issue of having to manually run go install commands after each change to the codebase in WSL. You can add a new task by clicking the + button in the Before launch section of the run configuration.

The task here is an External Tool type that runs the necessary commands to make sure the correct dependencies are installed and dolt is built before running the Bats test:

On the Windows frontend we use wsl command to interact with WSL. Our actual commands are run in a Bash shell, through the Arguments fields. We also specify our working directory to be $ProjectFileDir$, which is the root of our GoLand project, a.k.a. my workspace folder that contains Dolt and other repositories. Now to break down the commands:

bash -l -c "echo '$ProjectFileDir$'; \
set -ex; \
export IS_WINDOWS=false; \
export GOROOT=/usr/local/go; \
export GOPATH=\$HOME/go; \
export PATH=\$GOROOT/bin:\$GOPATH/bin:\$PATH; \
echo '>>> Checking ICU'; \
dpkg -s libicu-dev >/dev/null 2>&1; \
echo '>>> Go toolchain'; \
which go; go version; \
echo '>>> Building Dolt'; \
cd ./dolt/go; go install ./cmd/dolt; \
echo '>>> Verifying Dolt'; \
which dolt; dolt version; \
[ -f \$GOPATH/bin/dolt ] && ls -l \$GOPATH/bin/dolt || echo 'Dolt binary not found'" 2>&1 | tee /tmp/dolt_build.log 

When you pass this into the field it has to be a single line, I've only added line breaks here and \ for readability. There's a lot going on, but the main points are: print the project directory to know where we are, set up the Go toolchain environment variables, check that libicu-dev is installed (a Dolt CGO dependency), and finally build and verify dolt is installed. The 2>&1 | tee /tmp/dolt_build.log at the end is just to capture all the output into a log file in case something goes wrong. Although, I also use set -ex to make sure the script exits on error and prints each command as it's executed.

Now when we run our Bats test, we can be sure that dolt is built and ready to go with our changes. From here, it's just a matter of clicking the run button and seeing the results in the IDE.

Getting Around skiponwindows

Turns out not all Bats tests are created equal. Some tests have a skiponwindows call, which is meant to skip tests that are known to fail on Windows. This is usually due to some incompatibilities between Unix and Windows filesystems or commands. However, since we're running these tests in WSL, we can actually run these tests without issues (mileage may vary).

You may have noticed IS_WINDOWS=false; in the build task above. This is an environment variable that Dolt's test suite uses to determine if it's running on Windows or not. By setting it to false, we can trick the tests into thinking they're running on a Unix system, with one more step of course.

if [ -d "$WINDOWS_BASE_DIR"/Windows/System32 ] || [ "$IS_WINDOWS" == true ]; then
IS_WINDOWS = true
if [ ! -d "$WINDOWS_BASE_DIR"/batstmp ]; then
mkdir "$WINDOWS_BASE_DIR"/batstmp
fi
BATS_TMPDIR = `TMPDIR="$WINDOWS_BASE_DIR"/batstmp mktemp -d -t dolt-bats-tests-XXXXXX`
export BATS_TMPDIR
nativepath() {
wslpath -w "$1"
}
nativevar() {
eval export "$1" = "$2"
export WSLENV = "$1$3"
}
skiponwindows() {
skip "$1"
}
fi

This snippet is from integration-tests/bats/helper/windows-compat.bash, which is sourced by the skiponwindows function to skip tests. In the first conditional, we check the System32 directory or the IS_WINDOWS variable to determine if we're on Windows. We resolved the latter, but we can also invert the result of the directory check using !.

if [ ! -d "$WINDOWS_BASE_DIR"/Windows/System32 ] || [ "$IS_WINDOWS" == true ]; then

We should now be able to run all the tests, even those with the skiponwindows call. Just make sure to install the necessary dependencies in WSL first: I've used the chaching_sha2_password.bats test below, which requires mysql-client to be installed as an example:

wsl sudo apt update
wsl sudo apt install -y libicu-dev git bats mysql-client

C:\windows\system32\wsl.exe bash -l /mnt/c/Users/Elian/AppData/Roaming/JetBrains/GoLand2025.2/plugins/bashsupport-pro/bats-core/bin/bats \
  -F bashpro -f ^caching_sha2_password:[[:space:]]+user[[:space:]]+does[[:space:]]+not[[:space:]]+exist$ \
  -r --verbose-run --show-output-of-passing-tests --print-output-on-failure \
  /mnt/c/Users/Elian/dolt_workspace/dolt/integration-tests/bats/caching_sha2_password.bats
Testing started at 2:46 PM ...
1..1

# Successfully initialized dolt data repository.

# time="2025-10-07T14:46:42-07:00" level=warning msg="user and password are no longer supported in sql-server
# configuration files.Use CREATE USER and GRANT statements to manage user accounts."

# Starting server with Config HP="0.0.0.0:3617"|T="28800000"|R="false"|L="debug"

# time="2025-10-07T14:46:42-07:00" level=debug msg="Loading events"

# time="2025-10-07T14:46:42-07:00" level=debug msg="privileges.db already exists, not creating root superuser"

# time="2025-10-07T14:46:42-07:00" level=info msg="Server ready. Accepting connections."

# time="2025-10-07T14:46:42-07:00" level=warning msg="secure_file_priv is set to \"\", which is insecure."

# time="2025-10-07T14:46:42-07:00" level=warning msg="Any user with GRANT FILE privileges will be able to read any file
# which the sql-server process can read."

# time="2025-10-07T14:46:42-07:00" level=warning msg="Please consider restarting the server with secure_file_priv set to
# a safe (or non-existent) directory."

# time="2025-10-07T14:46:43-07:00" level=info msg=NewConnection DisableClientMultiStatements=true connectionID=1

# time="2025-10-07T14:46:43-07:00" level=error msg="No authentication methods available for authentication."

# time="2025-10-07T14:46:43-07:00" level=info msg=ConnectionClosed connectionID=1

# mysql: [Warning] Using a password on the command line interface can be insecure.

# ERROR 2012 (HY000): No authentication methods available for authentication.

# time="2025-10-07T14:46:43-07:00" level=info msg="Server closing listener. No longer accepting connections."

# time="2025-10-07T14:46:43-07:00" level=info msg="stats stopped: context canceled"

Conclusion

You don’t need to be on Linux to work comfortably with Dolt’s Bats suite. With GoLand, WSL, and BashSupportPro you can build and test with a single click. It might not solve every platform quirk, but it makes the Windows experience much smoother.

If you run into issues or want to ask questions, join us on Discord where the Dolt team and community hang out. We’re always around to talk about testing, development workflows, and ways to contribute. Check out our other blogs to learn more about how we build and test Dolt together.