I don't know - what was I thinking? Too early in the morning :) J/K :) - so yeah, I will have to formalize my thoughts a little more, maybe come up with an example. I will get back to you.
For now though - have you ever looked at JBehave? It expresses functionality in a generic way - then there is glue that binds the tests to actual running code that developers must write. So I think that this would work by defining the behavior of any client that should be essentially the same across all clients, and then writing different bindings of that behavior to each specific client. On Tue, Nov 29, 2011 at 10:02 AM, Jay Kreps <jay.kr...@gmail.com> wrote: > How would this work for non-java clients? > > -Jay > > On Tue, Nov 29, 2011 at 7:42 AM, Taylor Gautier <tgaut...@tagged.com> > wrote: > > > 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. > > > > On Mon, Nov 28, 2011 at 11:51 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > > > > > Dave wrote an excellent guide to implementing a kafka client here: > > > http://readthedocs.org/docs/brod/en/latest/spec.html < > d...@datadoghq.com > > > > > > > > > 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 site, inconsistent or no examples in > the > > > source, and inconsistent or no integration tests for the clients. > Overall > > > our approach to clients has been to be somewhat liberal in what we > except > > > on the assumption that something is better than nothing. Unfortunately > > the > > > clients are somewhat harmed by lack of a clear model to follow. > > > > > > I was thinking it might be good to have a standard for these and try to > > > move the clients towards these standards and only take new clients that > > > meet the standards. Here is what I was thinking should be a minimum for > > us > > > to take a client: > > > > > > - A patch for documentation > > > http://svn.apache.org/repos/asf/incubator/kafka/site that adds > > > quickstart style instructions for usage. We should make the existing > > > quickstart link a list with an entry for each language. > > > - An integration test suite which can be run against a running > > broker/zk > > > on the default port and localhost. Not sure of the best format for > > these, > > > but maybe just a shell script that can be invoked by doing > > > clients/<lang>/test.sh (the tests themselves can be in the client > > > language, > > > this just gives a uniform way to run them as part of a regression > > suite). > > > This script should exit with a non-zero code if one or more tests > fail > > > and > > > print diagnostic information. > > > - An entry in the examples examples/src/main/<lang> directory which > > > gives complete code for a working example. > > > - 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 > > > good to have a contact person who can be point for questions or > fixes. > > > - A self-assessment of the "production readiness" of the client. I > > think > > > it is fine to take proof-of-concept code since it gives people > > something > > > to > > > work from, but it is good to be able to give people some assessment > of > > > how > > > production-ready it is so people don't run into problems and have a > > > negative reaction to the project as a whole. > > > > > > Any other criteria we should add? > > > -Jay > > > > > >
