> > > Also, I've been thinking more and more about beefing up the JavaScript > test suite runner and moving more of our browser tests over to > dedicated code in those tests. If anyone's interested in hacking on > some C and JavaScript against an HTTP API, let me know.
Paul, Jan and I talked about this a few times and I started a branch[1] along that idea. So far all I did was make a copy of the then current Futon tests into test/javascript/test and started looking at the small handful that fail. The browser tests are great (any test is good) but they have too many browser dependent quirks, or at least I assume that because of the pleasant surprise one gets when they all run. So I think the goal of these runner tests would be some sort of official HTTP API suite that's part of "make check". Would you agree? If so I'm happy to take this on. Also I've found eunit to be helpful in BigCouch and wondering how hard it would be to support eunit in couchdb. Having tests in the modules is very good for not only testing but also to help with reading and understanding what the code does. Bob [1] https://github.com/bdionne/couchdb/tree/cli-tests
