Speed up test runs to ~30s (from 150s+)#390
Conversation
Signed-off-by: Mitch Gaffigan <mitch.gaffigan@comcast.net>
Signed-off-by: Mitch Gaffigan <mitch.gaffigan@comcast.net>
Signed-off-by: Mitch Gaffigan <mitch.gaffigan@comcast.net>
Signed-off-by: Mitch Gaffigan <mitch.gaffigan@comcast.net>
|
Sorry @NicoPiel, I had missed a push. Thanks for the review :) |
NicoPiel
left a comment
There was a problem hiding this comment.
No worries. I love these kinds of speed-ups.
pacmano1
left a comment
There was a problem hiding this comment.
Approving.
I'd probably comment on the changed address you used, so nobody "helpfully" fixes it later. The old 9s wasn't DNS. 111.1.1.1 is a valid literal, no lookup. It fails at bind() and hits the retry loop in TcpDispatcher.createServerSocket(): 10 tries, hardcoded sleep(1000) each.
256.256.256.256 isn't a valid literal, so getByName does a DNS lookup instead. Normally a fast NXDOMAIN, so it throws UnknownHostException and skips the loop. That's the speedup.
Fine for a test that just checks startup fails with ConnectorTaskException. Two things worth capturing: it's invalid on purpose (make it routable and the 9s loop is back), and it leans on the resolver returning NXDOMAIN fast. A slow or hijacking resolver brings the wait back the other way.
|
@pacmano1, agreed on all points. I was able to change the timeout on the receiver test (so that one could remain the valid 111.1.1.1), but did not see a clean way to do the same on the dispatcher test. Since the test is basically a duplicate of the receiver test, I left it with the DNS error. |
TcpDispatcherTest was doing lots of sleeping to for synchronization. Avoid that by using latches and other synchronization. Also: avoid 9s of waiting for the 111.1.1.1 IP to be bindable. Saves 90s or so.
TcpRecieverTest had another 10s of sleeps.
PropertiesConfig had another 7s.
Enabling parallel execution gave additional 20s+ back.
No expected behavior changes nor gaps in coverage. Tested in a loop for stability: