[ETCM-503] testing in CI takes a lot of time #877
Conversation
dmitry-worker
force-pushed
the
feature/ETCM-503-tests-timeout-in-ci
branch
from
96c8100 to
c728320
Compare
dmitry-worker
changed the title
dmitry-worker
requested review from
biandratti,
enriquerodbe,
faraggi and
lemastero
src/test/scala/io/iohk/ethereum/network/PeerStatisticsSpec.scala
Outdated
Show resolved
Hide resolved
| with SpecFixtures | ||
| with WithActorSystemShutDown { self => | ||
| implicit val timeout: Timeout = Timeout(10.seconds) | ||
| implicit val timeout: Timeout = Timeout(30.seconds) |
There was a problem hiding this comment.
Does this mean that we have some tests that take more than 10 seconds to complete? We should improve those. If that's out of the scope of this PR maybe we can create a task to improve those tests.
There was a problem hiding this comment.
Locally it runs for 2.6 seconds approximately. Maybe if I'll catch up with the logic of Fast/Regular sync it would be much easier to refactor these tests.
| // The time counter counter | ||
| clock: Clock | ||
| ) { |
There was a problem hiding this comment.
What was the problem with the way it was? I used an implicit just to make it a bit easier to return new instances of this otherwise immutable class.
There was a problem hiding this comment.
It also seemed to make some sense that different parts of the app shouldn't have different clocks, so passing around an implicit one to whoever needs it might be better than threading it through. But ultimately it was only passed on in once place in this class so I get it if you don't like it.
There was a problem hiding this comment.
Made clock implicit again
| // The following are implemented for completness' sake but not used: | ||
| override def getZone(): ZoneId = zoneId | ||
| override def withZone(x: ZoneId): Clock = new MockClock(currentTimeMillis, zoneId) | ||
| } No newline at end of file |
There was a problem hiding this comment.
You may want to configure your editor to add a newline at the end of the file.
Description
FastSyncSpec is failing one test repeatedly for some reason at CI... couldn't reproduce it locally..
Maybe it has something to do with a number of builds running simultaneously. They probably share the same hardware for testing.
Proposed Solution
Increase the timeout for a test.