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 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. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
