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