[infinispan-dev] Hot Rod testing

[Ion Savin]

Hi all,

> - 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

At least for some of this cases this approach could work for protocol 
level client tests:

Implement a tool (single process) which mocks the server side, can 
accept multiple connections from clients to simulate a cluster and can 
verify that the interaction with the client matches a predefined script.

There could be a separate script for each HR version / intelligence level.

The script is interpreted by the mock and not dependent on any of the 
languages in which the clients are implemented. All assertions are done 
in this tool and not the client (e.g. to test get() generate a random 
value and expect the client to do a put() on another key with the value 
it got using get()).

For each HR client implement a client app in that language which 
interacts with the mock as prescribed by the script.

This is very similar to how financial institution automate certification 
for FIX protocol implementations / integration work.

--
Ion Savin