[infinispan-dev] Hot Rod testing

[Gustavo Fernandes]

On Fri, Sep 30, 2016 at 9:40 AM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> On 23/09/16 17:33, Galder Zamarreño wrote:
> > ^ I thought about all of this when working on the JS client, and
> although like you, I thought this was the biggest hurdle, eventually I
> realised that there are bigger issues than that:
> >
> > 1. How do you verify that a Javascript client works the way a Javascript
> program would use it?
> > IOW, even if you could call JS from Java, what you'd be verifying is
> that whichever contorsionate way of calling JS from Java works, which might
> not necessarily mean it works when a real JS program calls it.
> If a specific language API wants to "feel native" in its environment
> that is fine, and there should be local tests to exercise that, but from
> a protocol compliance point of view this is irrelevant. We need to
> verify that:
>
> - for each Hot Rod operation and variant (e.g. flags, metadata) the
> client is sending the correct request.
> - the client should also be able to correctly process the response,
> again with different variations (result, not found, errors, metadata)
> - for the different client intelligence levels the client should be able
> to correctly process the returned headers  (topology, hashing, etc)
> - the client should correctly react to topology changes and failover
> - the client should correctly react to events and fire the appropriate
> listeners
> - the client should be able to correctly handle encryption handshaking
> and report error situations properly
> - the client should be able to correctly handle authentication and
> report error situations properly for the client-supported mechanisms
>


I wonder if something like Haxe [1] could help here in defining a language
agnostic
TCK (maybe an skeleton?) that gets compiled to several platforms. Each
platform's
testsuite would them "implement" the spec and of course would be free to
add
'native' tests as well. There's also a unit test framework built on top of
[1], worth exploring

[1] https://haxe.org/
[2] https://github.com/massiveinteractive/MassiveUnit/


> Additionally client might wish to test for the following, but this is
> not part of the protocol specification:
>
> - marshalling
> - async methods
> - site failover
> - language-specific synctactic sugar
>
> Also, to provide a common ground for the server configuration used by
> both types of tests (TCK and client-specific), we should really use
> docker containers with appropriately named configs together with common
> scripts that recreate the test scenarios, so that each testsuite doesn't
> have to reinvent the wheel.
>
>
+1 for docker, as it no longer requires the hack of having VirtualBox on
non-Linux platforms.
>From my experience, most of the testing cases don't even need huge
pre-canned XMLs, all
configurations can be achieved by runtime manipulation of the server model.

Cheers,
Gustavo


Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160930/3a6a3cb3/attachment-0001.html