GoDogLand BDD Runner

Godog and Cucumber workflows that feel native inside GoLand.

Run, debug, inspect, generate, and navigate BDD scenarios without bouncing between your terminal, feature files, and Go step definitions.

---

Why This Exists

BDD in Go is great once it is running. The rough part is everything around it: finding the right step definition, running one scenario, debugging a failing example, checking whether a step is still used, and wiring environment variables for the test command.

GoDogLand BDD Runner brings those daily Godog tasks into the GoLand editor. Your .feature file becomes a real control surface: click a scenario, run it, debug it, jump to Go code, see the latest status, and keep moving.

See It In Action

What You Get

• Run from the gutter
  Click beside a Feature or Scenario and run exactly what you are looking at.

• Debug Godog scenarios from .feature files
  Start a Godog scenario in GoLand's debugger and work with normal debug controls.

• Pass/fail status beside scenarios
  Recently executed features and scenarios show native GoLand-style status icons.

• Step navigation that goes both ways
  Jump from a Gherkin step to ctx.Step(...), and use Find Usages from a step definition to discover matching .feature steps.

• BDD inspections for Go projects
  Spot undefined steps, unused step definitions, invalid regexes, and ambiguous step definitions before they waste your test run.

• Generate missing step definitions
  Use the quick fix on an undefined Gherkin step to create the Go method and register it in a file that already owns a godog.ScenarioContext.

• Environment variables for test runs
  Configure default run-time environment variables or named presets and reuse them from gutter runs.

• GoLand test tool window integration
  Run output is shown in the IDE test runner, with scenario results mapped back to feature lines.

The Demo Project

This repository also contains a tiny Go application so the plugin has something concrete to run:

• features/training_points.feature contains sample Gherkin scenarios.
• features/training_points_test.go contains Godog step definitions.
• internal/training/ contains the small domain model under test.
• goland-plugin/ contains the GoLand plugin source.

The sample feature is intentionally easy to tweak. Change an expected value in the .feature file and you can flip a scenario between passing and failing, which makes the gutter status behavior easy to verify.

Quick Start

Build an installable GoLand plugin ZIP:

task build-plugin

The ZIP is created at:

build/godogland-bdd-runner.zip

Install it in GoLand:

Settings | Plugins | Install Plugin from Disk...

Then open features/training_points.feature and use the gutter icons beside Feature and Scenario.

Environment Presets

Use environment presets when you want to run the same feature or scenario with different run-time variables, for example against local services, a staging API, or a fake payment provider.

Open:

Settings | Tools | GoDogLand BDD Runner

The Default environment variables field keeps the old single-environment workflow. Add one variable per line:

API_URL=http://127.0.0.1
DOG_NAME=fake

The Named environment presets field lets you define multiple named environments in an INI-style format:

[Local]
API_URL=http://127.0.0.1
DOG_NAME=Frela

[Beta]
API_URL=https://api.example.com
DOG_NAME=Kefir

After saving the settings, open a .feature file and click the gutter icon next to a Feature or Scenario. If more than one preset is configured, GoDogLand shows preset-aware actions:

Run with Environment
  Local
  Beta

Debug with Environment
  Local
  Beta

Choosing a preset runs or debugs the same Godog target with that preset's environment variables. GoDogLand also adds GODOGLAND_BDD_ENV_PRESET to the test process, so test code can tell which preset was selected.

Verify Marketplace compatibility with JetBrains Plugin Verifier:

task verify-plugin

The first run downloads the verifier CLI into .task/plugin-verifier. By default it verifies against /Applications/GoLand.app/Contents; override it when needed:

GOLAND_HOME="/path/to/GoLand.app/Contents" task verify-plugin

Run lightweight Java unit tests for plugin logic:

task test-plugin-java

These tests compile the plugin classes against your local GoLand installation and exercise parser/status/generator logic without launching the IDE.

Sign the plugin ZIP before publishing:

PLUGIN_SIGN_KEY_PASSWORD="your-password" task sign-plugin
task verify-plugin-signature

By default the signing tasks read credentials from:

.secrets/plugin-signing/chain.crt
.secrets/plugin-signing/private.pem

Keep .secrets/ out of Git. To use different paths:

PLUGIN_SIGN_CERT_FILE="/path/to/chain.crt" \
PLUGIN_SIGN_KEY_FILE="/path/to/private.pem" \
PLUGIN_SIGN_KEY_PASSWORD="your-password" \
task sign-plugin

For a local/self-signed certificate, JetBrains documents this OpenSSL flow:

mkdir -p .secrets/plugin-signing
openssl genpkey -aes-256-cbc -algorithm RSA -out .secrets/plugin-signing/private_encrypted.pem -pkeyopt rsa_keygen_bits:4096
openssl rsa -in .secrets/plugin-signing/private_encrypted.pem -out .secrets/plugin-signing/private.pem
openssl req -key .secrets/plugin-signing/private.pem -new -x509 -days 365 -out .secrets/plugin-signing/chain.crt

GitHub Actions

The repository includes a plugin workflow at .github/workflows/plugin.yml:

• Pull requests to main run only the Java plugin tests.
• Pushes to main run plugin tests, run JetBrains Plugin Verifier, sign the plugin ZIP, create an annotated v<plugin.xml version> tag, and publish a GitHub Release with godogland-bdd-runner-signed.zip.

Add these repository secrets in GitHub:

PLUGIN_SIGN_CERTIFICATE_CHAIN
PLUGIN_SIGN_PRIVATE_KEY
PLUGIN_SIGN_KEY_PASSWORD

Use the contents of your local signing files:

pbcopy < .secrets/plugin-signing/chain.crt
# paste into PLUGIN_SIGN_CERTIFICATE_CHAIN

pbcopy < .secrets/plugin-signing/private.pem
# paste into PLUGIN_SIGN_PRIVATE_KEY

PLUGIN_SIGN_KEY_PASSWORD should be the password used for the signing key. The workflow writes those values into .secrets/plugin-signing/ only inside the CI runner.

Requirements

• GoLand 2026.1+ / build 261+ with the Go plugin
• JetBrains Gherkin plugin
• Go and the dependencies from go.mod
• Task for the provided Taskfile.yml

License

MIT. See LICENSE.