On 14 Feb 2009, at 18:59, kowsik wrote:
What we could do is to have a shell test-runner (in addition to the
browser) that uses spider monkey to execute the same set of tests.
This way you write the tests once and it works both within the browser
and the shell.
We have that. Run `make test` in trunk. :)
Cheers
Jan
--
K.
On Fri, Feb 13, 2009 at 10:36 AM, Damien Katz <[email protected]>
wrote:
On Feb 13, 2009, at 1:09 PM, Chris Anderson wrote:
On Fri, Feb 13, 2009 at 10:02 AM, Damien Katz <[email protected]>
wrote:
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.
That's funny, I've had sort of the opposite perspective. For
in-browser development, the Futon jQuery CouchDB library seems like
the defacto stadard. It supports asynchronous calls and has a nicer
abstraction layer than couch.js.
OTOH, couch.js makes a great reference for building non-JavaScript
libraries, as most languages don't use the asynchronous http request
model that JavaScript tends to, but couch.js avoids. I think that if
we concentrate on keeping couch.js at the right level of abstraction
for the test suite, we'll be happiest.
I agree that the test suite needs cleanup, but I don't think pulling
couch.js out of it will make it any clearer.
I don't do much browser development, so I'll concede I could be
completely
wrong about how couch.js is perceived and used.
-Damien
