You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see some failures about postgres not running, such as:
# golang.org/x/pkgsite/internal/middleware
internal/middleware/experiment_test.go:111:9: conversion from uint to string yields a string of one rune
2020/06/15 17:25:48 dial tcp [::1]:5432: connect: connection refused
FAIL golang.org/x/pkgsite/internal/database 0.022s
Two options:
Skip those tests if the connection is refused
Use some sort of alternative without external dependencies, like a mock or an in-memory store implementation
The first is probably the best in the short term.
The text was updated successfully, but these errors were encountered:
In general I would expect go test ./... to pass at head within any golang.org/x module without needing to install or start any services that aren't already standard in the development environment.
(I agree with @mvdan: some sort of opt-in to the non-hermetic tests would probably be a good idea. Would it be reasonable for the test to start and stop its own database, perhaps as a subprocess, if one isn't already running and exec.LookPath finds a suitable version?)
What @bcmills said. go test ./... should work on a clean clone of any Go module. For example, Go has plenty of tests that require special dependencies like git or gdb, and those are generally skipped when the tools aren't installed.
Documenting a way to run all tests the proper way is OK, but it shouldn't be a requirement to avoid failures :)
I see some failures about postgres not running, such as:
Two options:
The first is probably the best in the short term.
The text was updated successfully, but these errors were encountered: