On Apr 9, 2015, at 11:41 PM, John Sanda <jsanda@redhat.com> wrote:


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._______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

For an HTTP server you want something that is lightweight and easily embeddable, two criteria that most servlet containers do not satisfy. If tests are being written in Java, I would look at things like Jetty, Vert.x, Undertow, or RxNetty if you want to go the reactive route. And if tests aren’t being written in Java but even staying on the JVM, you might have even more options. With Clojure for example, http-kit has no dependencies other than the core Clojure runtime.