Tests will sometimes fail. Easy way to reproduce is run tests in a loop, for example:
for i in {1..100}; do go test -run RoundTrip; done;
With ~10% fail rate, you should see:
--- FAIL: TestRoundTrip (0.09s)
api_test.go:666: pkgs should have something in it; got 0, want 1
Tests will sometimes fail. Easy way to reproduce is run tests in a loop, for example:
for i in {1..100}; do go test -run RoundTrip; done;
With ~10% fail rate, you should see:
--- FAIL: TestRoundTrip (0.09s)
api_test.go:666: pkgs should have something in it; got 0, want 1
Here's good way to test that this has been solved (aside from making a test that reproduces this pathology, which we haven't done yet):
$ go test -c mcquay.me/vain
$ for i in {1..100}; do ./vain.test -test.Run RoundTrip; done
This gets around the overhead of compilation for every test as it compiles it once.
Here's good way to test that this has been solved (aside from making a test that reproduces this pathology, which we haven't done yet):
$ go test -c mcquay.me/vain
$ for i in {1..100}; do ./vain.test -test.Run RoundTrip; done
This gets around the overhead of compilation for every test as it compiles it once.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Tests will sometimes fail. Easy way to reproduce is run tests in a loop, for example:
for i in {1..100}; do go test -run RoundTrip; done;
With ~10% fail rate, you should see:
--- FAIL: TestRoundTrip (0.09s)
api_test.go:666: pkgs should have something in it; got 0, want 1
Here's good way to test that this has been solved (aside from making a test that reproduces this pathology, which we haven't done yet):
This gets around the overhead of compilation for every test as it compiles it once.
It's not sqlite:
https://grt.mcquay.me/#/c/9/
but I am starting to think it should just be in-memory and written to disk periodically.