Increase connection timeout if remote_debug=true, in order to give the remote debugger enough time to properly connect.
Increase connection timeout if remote_debug=true, in order to give th…
…e remote debugger enough time to properly connect.
We experience a minor inconvenience when remote-debugging fixture code (SLIM-based). We use the standard mechanism for executing tests (as described in http://fitnesse.org/FitNesse.UserGuide.DebugingFixtureCode). When connecting the remote debugger within Eclipse to the executing Fixture code, the FitNesse SLIM runner frequently reaches a timeout before the Eclipse debugger has established a connection. Googling for a solution, I only found some old postings from 2009 mentioning the same problem, but claimed it was Mac specific. Btw, I also run on a Mac, but I have observed the same behavior on one of my collegue's windows laptop.
Looking in the source code, I can see that the SlimCommandRunningClient.connect() method that has a timeout of 50 ms and a retry count of 100, which means that FitNesse/SLIM will timeout after 50*100 ms = 5 seconds. That is probably reasonable for a normal test run, but a bit too quick when running a test with remote debugging enabled.
It was a trivial change to increase the timeout to e.g. 250 ms * 100 retries = 25 seconds (conditionally of course, if remote_debug = true).
I don't like the fact that this is handled by a boolean. In the timeouts are still fixed values. I think a more elegant solution is possible.
I completely agree that the hard-coded timeouts are ugly. Isn't the debug setting kind of boolean, though: either you run your tests in remote debug mode, or you don't. In debug mode, a short timeout doesn't really make sense.
Do you think configurable timeouts would be a better solution?
I think they would. Maybe there are some possibilities in the test runner as well.
Add configurable timeout for running slim tests in debug mode.
Fixes #339. Now set a property "slim.debug.timeout", either in a page or in the configuration file.