mirror of
https://github.com/hanzoai/tasks.git
synced 2026-10-04 02:04:03 +00:00
Stephan BehnkeandGitHub
e267d540bd
## What changed?
Changed use of `testhooks`'s `Set` to be runtime error instead of
compile time error.
It still ensures that the default impl (used in `go build` artifacts
without `test_dep` tag) is the noop impl.
## Why?
When running a functional test via plain `go test` it will fail, as the
`test_dep` build flag is required. It is required to prevent
accidentally using the default/noop implementation of the `testhooks`
package which allows injecting custom behavior into production code from
tests.
But requiring `test_dep` to run any test adds friction: CLI invocations
need to specify it manually, editor setups need to be adjusted, AI
agents need to be instructed. That's a high price to pay for a test
helper that is used fairly sparsely.
## How did you test it?
- [ ] built
- [x] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
Functional test without testhook:
```
% go test ./tests -run "OwnershipLostErrorSuite" -count=1 .
ok go.temporal.io/server/tests 7.062s
```
Functional test with testhook and build tag:
```
% go test ./tests -run "TestUpdateWorkflowSuite" -tags test_dep -count=1 .
ok go.temporal.io/server/tests 36.975s
```
Functional test with testhook but no build tag:
```
% go test ./tests -run "TestUpdateWorkflowSuite" -count=1 .
...
noop_impl.go:39: test panicked: testhooks.Set called but TestHooks are not enabled: use -tags=test_dep when running `go test`
goroutine 33293 [running]:
runtime/debug.Stack()
...
FAIL
FAIL go.temporal.io/server/tests 57.128s
FAIL
```
44 lines
1.3 KiB
Go
44 lines
1.3 KiB
Go
//go:build !test_dep
|
|
|
|
package testhooks
|
|
|
|
import (
|
|
"go.uber.org/fx"
|
|
)
|
|
|
|
var Module = fx.Options(
|
|
fx.Provide(NewTestHooks),
|
|
)
|
|
|
|
// TestHooks (in production mode) is an empty struct just so the build works.
|
|
// See TestHooks in test_impl.go.
|
|
//
|
|
// TestHooks are an inherently unclean way of writing tests. They require mixing test-only
|
|
// concerns into production code. In general you should prefer other ways of writing tests
|
|
// wherever possible, and only use TestHooks sparingly, as a last resort.
|
|
type TestHooks struct{}
|
|
|
|
func NewTestHooks() TestHooks {
|
|
return TestHooks{}
|
|
}
|
|
|
|
// Get gets the value of a test hook. In production mode it always returns the zero value and
|
|
// false, which hopefully the compiler will inline and remove the hook as dead code.
|
|
//
|
|
// TestHooks should be used very sparingly, see comment on TestHooks.
|
|
func Get[T any](_ TestHooks, _ Key) (T, bool) {
|
|
var zero T
|
|
return zero, false
|
|
}
|
|
|
|
// Call calls a func() hook if present.
|
|
//
|
|
// TestHooks should be used very sparingly, see comment on TestHooks.
|
|
func Call(_ TestHooks, _ Key) {
|
|
}
|
|
|
|
// Set is only to be used by test code together with the test_dep build tag.
|
|
func Set[T any](_ TestHooks, _ Key, _ T) func() {
|
|
panic("testhooks.Set called but TestHooks are not enabled: use -tags=test_dep when running `go test`")
|
|
}
|