On Fri, Feb 13, 2009 at 1:52 PM, Chris Anderson <[email protected]> wrote: > On Fri, Feb 13, 2009 at 10:30 AM, Paul Davis > <[email protected]> wrote: >> >> 2. I'd still argue that we shouldn't be using a browser as our native >> test runner. We'd have to give up the little green check marks that >> make us all feel warm and fuzzy when tests pass, but the browser is a >> huge ass confounding variable. > > I know for sure that in-browser tests are a big part of what brought > me to CouchDB. They tell the story of a web-native database in a way > that nothing else can really touch. They also make it *incredibly > easy* for newcomers to contribute. >
Heh. I actually took a while to come around to the idea of the pure couch application. I see your point and I raise you though. I'm all for some snazzy looking tests in the browser, but I would argue that if we went with doing the basics for browser interaction we'd be set. Ie, CRUD operations, checking out _uuids and _bulk_docs etc etc. I'm thinking the Futon test suite could be similar to what it is, but instead of testing your couchdb install, it's testing your browser's conformance to working with CouchDB. Hell, we could even start a wiki page for "These browsers have passed the CouchDB test suite" type of thing. or run one of those render things on it too. >>To me, a proper test suite would be run >> from directly from the command line. We have the hacked together test >> runner, but not many people seem to use it regularly because we have >> the fancy green check marks. >> > > I think we're starting to feel the lack of Erlang unit tests. They > sure would have helped me in my last few patches, and they'd make a > decent beginning for documenting our native Erlang API. > > I think once we get the few Erlang tests that are already written, > integrated into the build, and make it easy to add new ones, they will > become the primary command-line test suite. > eunit tests are definitely important as well, but they're testing something completely different. I tend to look at my testing as a large tree. unit tests are at the very bottom making sure specific functions are working, then we test different combinations, and etc etc until we're at the top testing the user API. Purists hate me for saying that because they think that *everything* should be tested independently. I hate purists though so it all evens out. > Chris > > -- > Chris Anderson > http://jchris.mfdz.com > Also, s/trunk/host/ in my last. HTH, Paul Davis
