Files
dance-lessons-coach/documentation/BDD_GUIDE.md
Gabriel Radureau 52065c9cf3
Some checks failed
CI/CD Pipeline / Build Docker Cache (push) Successful in 10s
CI/CD Pipeline / CI Pipeline (push) Failing after 13s
refactor: convert all DanceLessonsCoach mentions to kebab-case
2026-04-07 19:11:39 +02:00

228 lines
5.7 KiB
Markdown

# BDD Testing Guide for dance-lessons-coach
This guide explains how to work with BDD tests using Godog in the dance-lessons-coach project.
## Installation
### Modern Go Approach (Recommended)
The idiomatic and modern way to install Godog for developers joining the project:
```bash
# Install Godog as a Go tool (recommended approach)
go install github.com/cucumber/godog/cmd/godog@latest
```
This installs the `godog` binary in your `$GOPATH/bin` directory. Make sure this directory is in your `PATH`.
### Alternative: Using go run
You can also run Godog directly without installing:
```bash
go run github.com/cucumber/godog/cmd/godog@latest
```
### Project Setup
The project already includes Godog as a dependency in `go.mod`. The BDD tests are integrated into the standard Go testing framework.
## Running BDD Tests
### Run All BDD Tests
```bash
# From project root
cd /Users/gabrielradureau/Work/Vibe/dance-lessons-coach
go test ./features/... -v
```
### Run Specific Feature
```bash
# Run only greet feature
go test ./features/... -v -run "TestBDD/Greet"
# Run only health feature
go test ./features/... -v -run "TestBDD/Health"
# Run only readiness feature
go test ./features/... -v -run "TestBDD/Readiness"
```
### Different Output Formats
```bash
# Progress format (default)
go test ./features/... -v
# Pretty format
go test ./features/... -v -godog.format=pretty
# JSON format
go test ./features/... -v -godog.format=json
# HTML report
go test ./features/... -v -godog.format=html > report.html
```
## Project Structure
```
features/
├── bdd_test.go # Main test entry point
├── greet.feature # Greet service feature
└── health.feature # Health endpoint feature
pkg/bdd/
├── steps/ # Step definitions
│ └── steps.go # All step definitions
├── testserver/ # Test infrastructure
│ ├── server.go # Test server management
│ └── client.go # HTTP client for testing
├── suite.go # Test suite initialization
└── README.md # BDD usage guide
```
## Writing New Features
### 1. Create Feature File
Create a new `.feature` file in the `features/` directory using Gherkin syntax:
```gherkin
# features/new_feature.feature
Feature: New Feature
Description of the new feature
Scenario: Happy path
Given some precondition
When I perform an action
Then I should see the expected result
```
### 2. Implement Step Definitions
Create a corresponding step definition file in `pkg/bdd/steps/`:
```go
// pkg/bdd/steps/new_feature_steps.go
package steps
import (
"dance-lessons-coach/pkg/bdd/testserver"
"github.com/cucumber/godog"
)
func InitializeNewFeatureSteps(ctx *godog.ScenarioContext, client *testserver.Client) {
ctx.Step(`^some precondition$`, func() error {
// Implementation
return nil
})
ctx.Step(`^I perform an action$`, func() error {
// Implementation
return nil
})
ctx.Step(`^I should see the expected result$`, func() error {
// Implementation
return nil
})
}
```
### 3. Register Steps
Add your step initialization to `pkg/bdd/suite.go`:
```go
func InitializeScenario(ctx *godog.ScenarioContext) {
server := testserver.NewServer()
client := testserver.NewClient(server)
// Initialize all steps using the unified approach
steps.InitializeAllSteps(ctx, client)
// ... cleanup code
}
```
## Best Practices
### Test Organization
- **One feature per file**: Keep feature files focused on a single capability
- **Clear scenario names**: Use descriptive scenario names that explain the behavior
- **Reusable steps**: Create reusable step definitions when possible
- **Black box testing**: Test through public APIs only, no internal knowledge
### Performance
- **Parallel execution**: Godog supports parallel scenario execution
- **Isolated scenarios**: Each scenario should be independent
- **Cleanup**: Always cleanup resources in `After` hooks
### Debugging
- **Verbose output**: Use `-v` flag for detailed output
- **Step-by-step**: Run with `-godog.tags=@focus` to run specific scenarios
- **Dry run**: Check step definitions without running tests
## Troubleshooting
### Server not starting
If tests fail with "server did not become ready", check:
- Port conflicts: `lsof -i :8080`
- Server logs: Check if server process starts properly
- Configuration: Verify config.yaml settings
### Missing step definitions
If you see "undefined steps", you need to:
1. Implement the missing step definitions
2. Register them in the suite initialization
3. Re-run the tests
### Test isolation issues
Ensure each scenario:
- Starts with a clean state
- Doesn't depend on other scenarios
- Properly cleans up resources
## CI/CD Integration
Add BDD tests to your CI pipeline:
```yaml
# Example GitHub Actions step
- name: Run BDD Tests
run: go test ./features/... -v
```
## Additional Resources
- [Godog GitHub](https://github.com/cucumber/godog)
- [Godog Documentation](https://github.com/cucumber/godog#readme)
- [Cucumber Documentation](https://cucumber.io/docs/gherkin/)
- [BDD Introduction](https://dannorth.net/introducing-bdd/)
## Modern Go Testing Practices
The dance-lessons-coach project follows modern Go testing practices:
1. **Standard library integration**: BDD tests use `go test`
2. **No global installation required**: Godog is a Go module dependency
3. **Cross-platform**: Works on all Go-supported platforms
4. **IDE integration**: Works with Go tools and IDEs
5. **Dependency management**: Versioned through go.mod
This approach ensures that:
- All developers use the same Godog version
- No manual installation steps are needed
- Tests work consistently across environments
- CI/CD integration is straightforward