with one click
tdd-unit-testing
// Write unit tests in Go following Red-Green-Refactor TDD principles.
// Write unit tests in Go following Red-Green-Refactor TDD principles.
Define and implement services that encapsulate business logic with proper constructor-based dependency injection.
Implement HTTP handlers that parse requests, invoke use cases, and format responses following REST conventions.
Build pluggable authentication features using the plugin system with initialization, migrations, routes, and service registration.
Implement repository interfaces for data persistence and abstraction over database operations using Bun ORM.
Orchestrate services and repositories through use cases to implement application-level workflows and business scenarios.
Wire dependencies using constructor-based dependency injection throughout services, repositories, and handlers.
| name | tdd-unit-testing |
| description | Write unit tests in Go following Red-Green-Refactor TDD principles. |
mocks.go file under a tests folder within the package being testedtt patterns for multiple cases, keep tests focused and small with one behavior per test case and test success and error paths.TestTodoService_CreateTodo and all the scenarios and logic should be tested as individual test cases using the table driven approachnew() function in Go 1.26+ to initialise reference type values instead of creating pointer functions that return a reference type. For example, use new("user-1") instead of a function such as ptrString("user-1") that returns *string to create a pointer to a string value. This also includes all other reference types such as new(10) for *int, new(true) for *bool, etc.AssertExpectations(t) at the end of tests that use mocks to ensure all expected calls were made.internals folder as it contains helpers and utils for tests. If a helper function or util is needed then see whether it is something that is global and can be used across the codebase but if it is specific to a plugin, then keep it local to the plugin by putting the helpers and utils within the plugin's tests folder. Never write test code differently in each handler, service, or repository test file. Always follow the same patterns and principles to ensure consistency and maintainability across all tests.Handlers: Create handler struct with UseCase/Service field; return http.HandlerFunc from Handler() method; test via httptest
Services: Mock repositories; test business logic and error handling
Repositories: Test against real SQLite database (Bun ORM); use test fixtures to set up schema
Integration tests: Use fixtures; test plugin routes end-to-end
Every test follows Arrange-Act-Assert (AAA):
See examples/ for Todos testing patterns:
test_helpers.go - MockTodoUseCase and MockTodoService interfaceshandler_test.go - Handler struct with UseCase, Handler() method, httptest patternsrepository_test.go - Real SQLite database tests with test fixtures, CRUD operationstodo_service_test.go - Service tests with mocked repositories and table-driven testsplugin_integration_test.go - End-to-end route testing with fixturesAssertExpectations(t)make test # Run all tests
make coverage # With coverage
go test -run TestFunc ... # Specific test
go test -race ./... # Detect race conditions