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
>> which implements
I feel, but I'm not sure, that we first need to define what we want to test:
I mean enumerate and organize the requirements could probably be the right
starting point.
Of course Sebastian's approach could be right if we can imagine a tool that can
enforce a requirement's organizational model.
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
> which implements the functionality of a group MUST pass all of the tests
> in
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 turni
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 s
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
I
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
w
On Thu, Sep 15, 2016 at 12:33 PM, Sanne Grinovero
wrote:
> 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
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 sev
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 o
10 matches
Mail list logo
