>
>
>
> 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
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
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
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
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,
>> 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
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
>
&
--
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
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
.
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
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
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
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
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
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
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
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
17 matches
Mail list logo