couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <dio...@dionne-associates.com>
Subject Re: Futon Test Suite
Date Sun, 14 Aug 2011 12:50:33 GMT
Paul,

  This is interesting, and if you're willing to put together the new infrastructure I can
help with writing tests. I would suggest a more incremental approach that's less of a rewrite
(rewrites often just get you back to 0 from a user's perspective). 

   The existing CouchDB JS object seems to work ok in terms of the http interface, and the
Futon tests more or less all ran using couchjs until very recently. I would suggest getting
these all running first, reusing copies of the existing CouchDB objects and such so we can
hack them as needed. Then we would review and throw out all the tests that are not part of
the core APIs, like the coffee stuff (I don't know why we decided to bundle coffee in there)
and any tests that are for specific internals.

   At some point something like BigCouch is integrated in or MobileCouch we might have different
"make" targets for the different deployments. Perhaps in that case we'd have different sets
of tests. There needs to be a set of tests that can verify that the semantics of API calls
is the same in CouchDB and BigCouch.

  So I'd say let's work backwards from what we have. Also I'm not a big fan of etap, preferring
eunit mainly because it's one less moving part. For JS we already have this T(...) and TEquals(....)
funs which seem to do the trick.

   All that said, I have a few hours today to hack on this today if you want some help just
ping me on #couchdb

Bob




On Aug 12, 2011, at 11:46 AM, Paul Davis wrote:

> Here's a bit of a brain dump on the sort of environment I'd like to
> see our CLI JS tests have. If anyone has any thoughts I'd like to hear
> them. Otherwise I'll start hacking on this at some point over the
> weekend.
> 
> https://gist.github.com/1142306


Mime
View raw message