Closed lookfirst closed 1 year ago
fyi this was a test that was failing prior to v0.9 as well
might even date further back
please run tests with parallel flag = 1 (-p 1) like this go test -short -v -p 1 ./...
--- FAIL: TestClaimProtoTx/claim_tx_from_a_proto_with_proto_codec (0.28s)
panic: failed to listen on 0.0.0.0:36657: listen tcp 0.0.0.0:36657: bind: address already in use [recovered]
panic: failed to listen on 0.0.0.0:36657: listen tcp 0.0.0.0:36657: bind: address already in use
^ this shows that if tests are executed in parallel the address bindings overlaps
@oten91 This seems to work, but woah, it is slow af. I'm on a top of the line m1 max with 64 gigs of ram and it is taking forever to run all the tests. I don't think this is a good solution.
Yeah, it takes around 10 minutes. They way most test are constructed they usually spawn a node and expects a result, parallel execution may change the expected result if shared between multiple tests. One possible solution is to randomize the ports bindings for each execution and client queries.
What's the benefit of spawning a node each time vs. say ... architecting the tests to just call into the node's api directly and not spawn anything?
Describe the bug check out staging branch, try to run tests.
To Reproduce
Expected behavior Tests pass.
Operating System or Platform: OSX