Re: [infinispan-dev] Hot Rod testing

2016-09-30 Thread Gustavo Fernandes
> > > > 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

Re: [infinispan-dev] Hot Rod testing

2016-09-30 Thread 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

Re: [infinispan-dev] Hot Rod testing

2016-09-30 Thread Gustavo Fernandes
On Fri, Sep 30, 2016 at 9:40 AM, Tristan Tarrant 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

Re: [infinispan-dev] Hot Rod testing

2016-09-30 Thread Tristan Tarrant
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

Re: [infinispan-dev] Hot Rod testing

2016-09-30 Thread Emmanuel Bernard
On Fri 2016-09-23 17:33, Galder Zamarreño wrote: >Maybe some day we'll have a Java-based testsuite that more easily allows >continous testing. Scala, through SBT, do have something along this lines, so >I don't think it's necessarily impossible, but we're not there yet. And, as I >said above,

Re: [infinispan-dev] Hot Rod testing

2016-09-30 Thread Emmanuel Bernard
>> 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

Re: [infinispan-dev] Hot Rod testing

2016-09-23 Thread Alan Field
Hey Galder, - Original Message - > From: "Galder Zamarreño" <gal...@redhat.com> > To: "infinispan -Dev List" <infinispan-dev@lists.jboss.org> > Sent: Friday, September 23, 2016 11:33:12 AM > Subject: Re: [infinispan-dev] Hot Rod testing > &

Re: [infinispan-dev] Hot Rod testing

2016-09-23 Thread Galder Zamarreño
-- Galder Zamarreño Infinispan, Red Hat > On 15 Sep 2016, at 13:58, Sebastian Laskawiec wrote: > > How about turning the problem upside down and creating a TCK suite which runs > on JUnit and has pluggable clients? The TCK suite would be responsible for > bootstrapping

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Dan Berindei
On Thu, Sep 15, 2016 at 7:42 PM, Alan Field wrote: > I also like this idea for a Unit-Based TCK for all clients, if this is > possible. > >> - we identify and group the tests depending on their scope (basic >> protocol ops, bulk ops, topology/failover, security, etc). A client

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Vittorio Rigamonti
. Vittorio - Original Message - From: "Tristan Tarrant" <ttarr...@redhat.com> To: infinispan-dev@lists.jboss.org Sent: Thursday, September 15, 2016 6:27:54 PM Subject: Re: [infinispan-dev] Hot Rod testing Anyway, I like the idea. Can we sketch a POC ? Tristan On 15/09/1

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Alan Field
gt; Sent: Thursday, September 15, 2016 12:27:54 PM > Subject: Re: [infinispan-dev] Hot Rod testing > > Anyway, I like the idea. Can we sketch a POC ? > > Tristan > > > On 15/09/16 14:24, Tristan Tarrant wrote: > > Whatever we choose, this solves only half of the

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Tristan Tarrant
Anyway, I like the idea. Can we sketch a POC ? Tristan On 15/09/16 14:24, Tristan Tarrant wrote: > Whatever we choose, this solves only half of the problem: enumerating > and classifying the tests is the hard part. > > Tristan > > On 15/09/16 13:58, Sebastian Laskawiec wrote: >> How about

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Tristan Tarrant
Whatever we choose, this solves only half of the problem: enumerating and classifying the tests is the hard part. Tristan On 15/09/16 13:58, Sebastian Laskawiec wrote: > How about turning the problem upside down and creating a TCK suite > which runs on JUnit and has pluggable clients? The TCK

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Tristan Tarrant
On 15/09/16 13:33, Sanne Grinovero wrote: > Especially the server is not even available via Maven coordinates. You didn't try hard enough: org.infinispan.server:infinispan-server:9.0.0.Alpha4:zip:bin org.infinispan.server infinispan-server 9.0.0.Alpha4 zip bin :) Tristan -- Tristan Tarrant

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Sebastian Laskawiec
How about turning the problem upside down and creating a TCK suite which runs on JUnit and has pluggable clients? The TCK suite would be responsible for bootstrapping servers, turning them down and validating the results. The biggest advantage of this approach is that all those things are pretty

Re: [infinispan-dev] Hot Rod testing

2016-09-15 Thread Sanne Grinovero
I was actually planning to start a similar topic, but from the point of view of user's testing needs. I've recently created Hibernate OGM support for Hot Rod, and it wasn't as easy as other NoSQL databases to test; luckily I have some knowledge and contact on Infinispan ;) but I had to develop

[infinispan-dev] Hot Rod testing

2016-09-15 Thread Tristan Tarrant
Recently I've had a chat with Galder, Will and Vittorio about how we test the Hot Rod server module and the various clients. We also discussed some of this in the past, but we now need to move forward with a better strategy. First up is the Hot Rod server module testsuite: it is the only part