couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karel Minařík <karel.mina...@gmail.com>
Subject Tests/TDD for CouchDB views
Date Sat, 07 Nov 2009 13:31:04 GMT
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


Mime
View raw message