On Apr 9, 2015, at 11:41 PM, John Sanda <jsanda(a)redhat.com>
wrote:
>
> On Apr 9, 2015, at 10:33 PM, mike thompson <mithomps(a)redhat.com
<mailto:mithomps@redhat.com>> wrote:
>
>>
>> On 9 Apr 2015, at 19:24, mike thompson <mithomps(a)redhat.com
<mailto: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(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
<
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.