couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Ideas for Changes to the Test Suite
Date Fri, 13 Feb 2009 18:30:22 GMT
Couple of thoughts:


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. 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.

If people want to have a set of tests for a browser as in "Your
browser must support this set of operations to be used with CouchDB"
I'm all for it, but other wise its just adding headaches.

Also, making sure that all data is run from the command line means we
can integrate it into a build bot. This means we know who to yell at
if someone breaks trunk. This is a good thing IMO.

3. My spoon is tooooo big! Or the tests in this case. But its funnier
with the talking banana mental image. Making test cases smaller and
more focused is a good thing. Some sort of shallow directory layout
could be useful for categorization. And I'd argue for one file per

4. Crazy idea on tagging. This is a bit off the deep end, but it'd be
kinda neat to have tagging support for tests. then if you have 5
seemingly random tests fail you'd realize that they all touch the
_uuid's endpoint or something. Just a random thought.

5. Also, there's an issue on JIRA to get a page so that people can
write tests cases from within Futon. Hopefully this would motivate new
people in the community to write tests that they can then upload to
JIRA (manually, of course, lawyers ftw).

6. I don't really have an opinion on couch.js. I can see both Damien
and Chris's arguments but I'm not overly concerned. When I was playing
with ajaxy bling with CouchDB I was just using jquery's normal ajax
support without any sort of library. The API is so thin I didn't even
stop to think that I'd want a  library in the first place. Granted I'm
a bit familiar with the API.


I have no idea why I made that a numbered list. But I'm too lazy to
change it now.

Paul Davis

On Fri, Feb 13, 2009 at 1:02 PM, Damien Katz <> wrote:
> So there have been some grumbling that the test suite could use some
> changes.
> A small problem I see is the use of couch.js in the tests.  I'd personally
> like to remove the Javascript couch.js library usage from the tests and
> instead use more naked HTTP calls and simple sub-routines.
> My biggest reason is clarity, the tests are like documentation and by
> removing a layer of abstraction the tests are easier to understand for
> exactly what they are testing. A simpler (if longer) test implementation
> makes it easier to build and debug libraries for other platforms.
> My other reason to drop couch.js from the test is it risks becoming the
> defacto JS library, and not a very good one. Because we are trying to keep
> it simple for the tests, it doesn't have lots of features that would be more
> useful for real development (like async support). I'd prefer couch.js be
> exactly what it needs to be for useful in a browser without serving the
> needs of the test suite.
> I'd like to know what others thing about that idea. It's a big task, lots of
> code in the test to modify.
> A bigger problem is the tests are just getting numerous and not very well
> organized. And it's only getting worse. I'm thinking we need to categorize
> the tests somehow to run subsets easily, but I don't have any concrete
> ideas. Suggestions welcome.
> -Damien

View raw message