On Feb 13, 2009, at 7:03 PM, Jan Lehnardt wrote:
On 14 Feb 2009, at 00:55, Antony Blakey wrote:
We shouldn't have in-browser tests. In-browser tests are about
testing the browser, which we shouldn't do in this project. Our
tests should be about Couch, on the command-line, build-farm-
integratable.
We have both and we can keep both as both are useful.
Given that CouchApps are a first class citizen, browser
based tests make a lot of sense.
I second this, the browser is a an app critical to CouchDB's success.
When I svn update I run the Futon tests in Safari, Firefox, Webkit
and using standalone runner. The more application paths to the server
to more bugs are exposed.
It was suggested earlier that we use Eunit (http://svn.process-
one.net/contribs/trunk/eunit/doc/overview-summary.html). It's got
some nice features and macros for building suites of tests, timers,
etc...
With a proper header the build could run Eunits and also strip the
test code from the distribution if desired, though I think they are
useful for code readers to learn the code.
I also prefer tests in separate modules, certain modules, .eg.
couch_btree or any module with lots of private functions are best
with tests in the files. Eunit supports both modes nicely with naming
conventions. There is even a LET macro for fans of lambda calculus :)
Cheers
Jan
--
