On Apr 9, 2015, at 10:33 PM, mike thompson <mithomps@redhat.com> wrote:


On 9 Apr 2015, at 19:24, mike thompson <mithomps@redhat.com> wrote:

I guess this question is mainly targeted to Hawkular QE. So all of my testing (especially on a dev box) shows availability 100% (as most sites will). So while I can mock this in code to show downtime and unknown. It appears that we need a consistent way to demonstrate up/down/unknown/whatever else. Is there a QE way to do this currently?

I’m thinking a mock site that changes states every 5 or 10 minutes that is publicly available. This way we could all link our integration tests to this site to provide full coverage of states(and there could be other availability states like I have mentioned in other Hawkular ML mails).

The use case I want to add is as a developer I want to test all availability states within a half hour (or whatever timeframe, but as everything waits on tests passing less is better) by pulling in certain site(s).

Ideas?
This can be as simple as having a servlet that cycles through response codes 2xx, 404, 5xx in a predictable manner. (content is irrelevant on status codes matter so should be easy). This way we could expect http status codes to change every 5 minutes: '12:00' -> ‘up’, 12:05 -> ‘down’, ’12:10’ -> ‘unknown’. So that it changes in a predictable way.

Anyway, just an idea…

Obviously, if this idea is legit, it can expanded in may different ways down in the future.

I think there are a couple different concerns here. The first is simulating a resource that returns the various response codes. That should be easy enough. It is just a matter of starting up an HTTP server in a different thread that returns status codes in a known, predictable order. The second involving time is more challenging in my opinion. This was a big challenge for me when I was trying to write automated tests for aggregation in RHQ. The aggregation job ran hourly and computed hourly rollups, 6 hr rollups, and 24 hr rollups. Having tests run for 24 hrs in order to produce a 24 hr rollup was not practical. I encapsulated most of the date/time functionality in a service that could easily be stubbed or mocked. I also avoided calls like System.currentTimeMillis() or DateTime.now() in production code. Instead I used DateTimeService.currentTime() which I could easily override with test stubs. With these and other similar types of strategies, I think you should be able to test availability in milliseconds or seconds, not minutes.