james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Tellier <be...@minet.net>
Subject Re: jmap-integration-testing (was : Re: My thoughts on JMAP implementation)
Date Mon, 14 Dec 2015 10:23:53 GMT

Le 14/12/2015 08:42, Matthieu Baechler a écrit :
> On 13/12/2015 12:43, Tellier Benoit wrote:
> [...]
>>    - jmap-integration-testing project is strange to me.
>>        1/ Its location. I think it has nothing to do in protocols, and
>> would rather see it in a new folder. Something like
>> /server/integration-tests/jmap/cassandra .(again server/protocols is,
>> according to me, about decoding requests and encoding responses)
> jmap-integration-testing aims at testing jmap protocol. It makes sense
> to have it next to jmap.
> About whether it should be next to server/protocols/jmap or
> protocols/jmap : it's integration tests, we need a server running, so
> server/protocols/jmap seems to be the best fit. Do you agree ?


>>        2/ I think you should make it easier for one to implement other
>> backends, and separate Cassandra stuff from generalizable testing stuff.
> To some degree, I disagree with the "everything must be generic" policy.
> On one hand, it's not a problem to put interfaces to be able to switch
> implementation of various part of James and it's what we did in jmap (we
> don't have any dependency on a specific backend).
> On the other hand, testing every configuration is a dead-end. Tests are
> already too long to execute and cartesian product of pluggable parts is
> really huge.

:-) I agree, cartesian product is hard ...

> So our take is : just allow anybody to test the configuration it want
> (after all, it's just a matter of splitting today
> jmap-integration-testing in two parts) but don't pay upfront the cost of
> having those configurations tested.


It makes even more sens as back-ends already a standard behavior
normalized by both Mapper unit tests and IMAP MPT integration tests. (If
I were you, I would even have loaded the memory mailbox to speed test up).

> Obviously it is a choice we can discuss further if anybody feels it's a
> critical design decision.

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message