Hello,
I have couple of questions regarding testing the logic in CouchDB
views, more precisely TDD for map/reduce algorithms. I was not able to
find too much info about best practices, recommendations, concrete
examples, whatever. (Notable exception being [1], but that is tied to
CouchRest.)
From what I understand (and I may be completely wrong about that),
views ("design documents") are an essential tool to query/filter the
datasets and, equally important, one way of implementing relations
[2]. Thus, they provide essential features, which should be 100%
reliable.
So, my questions are basically these:
* How do would you write/implement tests for your views? I have
noticed Jan has "test" fixture as attribute in _design/janl-onair [3]
Is this recommended practice? Or would it be better to "prepare" the
views in a separate database and copy them over to the real one
afterwards? Or ...?
* What is the recommended practice for writing the views? In Futon? In
an editor and uploading them to db via couchapp or similar? Via
CouchRest or similar layer?
* Is it possible to write views "test-first|driven", ie. setting up
some fixtures, writing the view, etc? Does it even make sense in
CouchDB context?
* Is there a way to automatically run such test suites? (Via browser,
or something like Rhino?)
* I see Futon has a Custom Test feature, but is it just a testbench,
while the tests cannot be saved?
* Regarding application logic itself, what would be the best/preferred
way to test CouchDB-backed models in eg. Rails app? Using eg. FakeWeb
[4] to mock responses and work with those? Or setting up and using
another CouchDB database (like Rails does for *SQL dbs)? The Peepcode
screencast on CouchDB [5] doesn't provide any pointers here.
As said, I may completely mis-understand the context here. But, the
thing is: I may be responsible for some CouchDB project, and given the
essential role views play in a database, I am worried about anyone
just writing some ad-hoc JavaScript inside Futon, clicking around one/
two times, and saving the code as permanent test. (Only to discover it
doesn't work a day later, re-indexing all the database, etc.)
Sorry if I mix all sorts of things into one and for such lengthy
message -- this is an area when I seem to be lost. I would happily
serve as a guinea pig for testing things out, providing feedback, etc.
Thanks!,
Karel
[1] http://upstream-berlin.com/2009/10/30/unit-testing-couchdb-views-with-couch-potato/
[2] http://www.cmlenz.net/archives/2007/10/couchdb-joins
[3] http://github.com/janl/onair/blob/master/test/fixtures/airtem.json
[4] http://fakeweb.rubyforge.org
[5] http://peepcode.com/products/couchdb-with-rails
--
www.karmi.cz
|