I agree about the importance of getting a general set of integration tests
to use against clients. I filed a JIRA for this, let's discuss approaches
to building this there. People mentioned different libraries or ideas, can
folks help flesh out their ideas on the JIRA so we can get to a concrete
de
Hi folks,
I think the single most important thing the project can do to
encourage driver development is to make the solid set of integration
tests that others in this thread have been talking about. Without
those tests, I could easily see myself mis-implementing compression in
such a way that I br
May I suggest a BDD approach? Having a set of acceptance tests would
pretty much cover it I think. I've used JBehave (http://jbehave.org/)
successfully in the past.
Using JBehave you would have a black-box approach to implementing automated
acceptance tests that every client should adhere to.
O
Would the owner have commit rights (even if just to that client code part
of the tree) ?
On Tue, Nov 29, 2011 at 2:51 AM, Jay Kreps wrote:
> - An owner for this client who would be willing to maintain this code
> going forward. This probably isn't a hugely time consuming job, but it is
>
For the testing purposes it would be extremely useful to have a generic set
of packets defined to unit test what a client must be able generate and
receive. Then each client can be certified by testing against a known set
of expectations for the packet parsing & generation rather than having to
br
Dave wrote an excellent guide to implementing a kafka client here:
http://readthedocs.org/docs/brod/en/latest/spec.html
One point that was raised in the discussion was that we don't currently
have a lot of standardization or documentation for clients. For example
there is no documentation on the
