Re: [infinispan-dev] Hot Rod testing
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