>> I don't have a dog in this fight (.ie. a paying customer) so this failure >> doesn't bother me. With respect to policy, given the various bogocities of >> browsers, I'd recommend something like these CLI tests plus the etaps ought >> to be the "official" tests for vetting, and part of the build > > Not that I disagree, but part (most?) of the appeal of the browser based > tests are that they run in a real-world client instead of the lab that is > couchjs+http :) >
The tests in Futon should be treated just as the tests for any other client library: a way to check the client. Instead we treat them as 75% of the tests for the CouchDB implementation. That's bad. Its like surgery with pruning shears. I don't know if the JS CLI runner is the way forward or not, or some other scripting language. But there should be a clear separation between what goes into Futon and what doesn't based on the "What are we trying to test?" question. On the flip side, I also think that the Futon tests would be a great place to 'document' the entire API. Then they could double as a "this browser is compatible with CouchDB" screen as well as a "this server is Couch-y" regardless of what the actual implementation is. Paul
