Abort tests if URL is unreachable

Imagine having a suite of integration-y tests that use some service that’s fickle and may be down occasionally and that you’re ok with not running the tests if it isn’t reachable.

Enter DisabledIfUnreachable extension!

@DisabledIfUnreachable(url = "some.url", timeoutMillis = 5_000)
class FickleServiceRelatedTests {

	void testA() {
		// something with the service
	}

	@DisabledIfUnreachable(url = "some.other.url", timeoutMillis = 5_000)
	void testB() {
		// something else with the service
	}

}

Test A is disabled if some.url isn’t reachable (i.e. times out in 5 seconds or returns a status code outside of 200-399). Same for B but it is also disabled if some.other.url isn’t reachable.

I’ve started playing with this idea a few years ago and have just put the code I wrote into this gist (which should be seen as experimental and not up to our quality standards; also it uses EnabledIf wording, but I don’t think that’s a good idea).

[Michael1993]

Hm, I’m not a 100% sure that an annotation is the proper place for what is essentially an assumption.

We should consider providing this functionality in the form of a utility class (e.g. PioneerAssumptions) with an assumeUrlIsReachable(String url, int timeoutMillis)

[Bukama]

Thinking this over, I realized that I couldn’t draw a clear boundary between uses cases for conditions (i.e. disabling a test) and for assumptions (i.e. aborting it). JUnit says:

Assumptions are typically used whenever it does not make sense to continue execution of a given test method — for example, if the test depends on something that does not exist in the current runtime environment.

That strongly suggests that this should indeed be an assumption. (I’m not 100% sure whether JDK versions and OSes shouldn’t be assumption as well [or this!], then, but that’s beside the point.) I’ll update the issue accordingly.

I’m totally with you: This cleary is an assumption.