4 ms·
well written post! one minor thing: I've skipped using build tags for integration tests because those tests will be out of sync one day with your main code, ev
by cyri 3y ago
well written post!
one minor thing: I've skipped using build tags for integration tests because those tests will be out of sync one day with your main code, even with Goland (?).
Instead I use the usual test and check if an environment variable is set, if not, then
t.Skipf("env var %q not set, skipping integration test",envVarName)
or you can use an additional CLI flag, e.g. in `feature_test.go` write
func init() { flagIntegration := flag.Bool("test.integration",false,"run int tests") }
then
$ go test -v -test.integration
- maerF0x0 3y ago> integration tests because those tests will be out of sync one day with your main code What do you mean here? What would be out of sync, and what would happen if it were?
- Crowberry 3y agoI usually make use of the long and short testmodes that are supported https://stackoverflow.com/questions/55180613/how-do-i-write-test-in-go-that-make-use-of-the-short-flag-and-can-it-be-combine https://stackoverflow.com/questions/55180613/how-do-i-write-... I used to use buildflags before this, but my linter ignored those files so they were hard to maintain
- puika 3y agoadditionally, if it's an integration test, you may want to always run with `-count=1` at least. e.g. if you use a DB, you certainly want to not skip any cached tests when the schema changes, etc.