Hi Thomas, I recently added unit tests for map/reduce functions to Couch Potato. It is written in Ruby, but it shouldn't be too hard to port this to whatever language. I have written a little blog post on how to use it here: http://upstre.am/2009/10/30/unit-testing-couchdb-views-with-couch-potato/
And here's the code: http://github.com/langalex/couch_potato/tree/master/lib/couch_potato/rspec Cheers Alex On Dec 27, 2009, at 20:09 PM, Thomas Vander Stichele wrote: > Hi everyone, > > this is my first mail to this list. Let's start by saying that I think > CouchDB is wonderful! > > I've been playing with it to write a Getting Things Done application so > that I can use it on my laptop, my two desktops, and my N900 phone. So > far the good part. > > The bad part currently is that I have a lot of friction when trying to > write view/show functions. Simple mistakes in my js code trigger > strange and cryptic warnings and problems in couchdb. Without going > into much detail, the things that have happened to me: > > - long waits, OS timeout errors from couchdb log > - couchdb view server completely crashing, resulting in a 404 (with the > next request then connecting, but still failing) > - long strings of numbers, longer than my terminal buffer, which I > think (with my limited knowledge of Erlang) are actual text documents > (in erlang, a string is really an array of numbers, right ?), but get > printed in this non-readable base format, filling up my terminal > scrollback buffer so I can't even see the errors in front of it. > > These are problems triggered by simple mistakes (referencing an > undefined 'name', accessing a property that doesn't exist, ...) which in > other languages I'm used to would simply tell me so when I run the > files. > > It helps to run 'js' on the files before even pushing the files to my > couchdb server, but even then I can still make other mistakes. And > frankly, the whole cycle of write-save-couchapp push-switch to > browser-reload page-switch to couchdb terminal to see error is > error-prone; often I realize on the refresh that I either forgot to save > the new .js file or push it to the server. > > So I thought it would make sense to add some unit tests to test my show > and view functions. > > It turns out this is not a very obvious thing to do. Most javascript > unit test frameworks are browser-based. I found JSUnit which can indeed > be run with spidermonkey. > > However, I've been racking my brain trying to figure out how I can make > js load for example a show function file, which contains an anonymous > function body, store it in a function object, then execute it: > > - spidermonkey has a function called 'load', but that reads and > executes the file; since the function is anonymous, it doesn't get > stored > - eval would work, since it returns the result of the last statement, > which in this case is the anonymous function definition; hence the > function. However, it doesn't seem like spidermonkey js gives me any > way to actually load files. > > So, I'm kind of surprised. Is anyone of you out there doing any kind of > unit testing against the .js code they write for views and shows and > maps and reduces ? I haven't even started on writing some tests for my > date formatting code, but I'd be annoyed if there was no good way to do > it in the future. > > Here's hoping someone has done something that works and can point me to > some source code repository as an example. > > Thanks! > Thomas > > -- > And I know > they all look so good from a distance > but I tell you I'm the one > -- > URGent, best radio on the net - 24/7 ! > http://urgent.fm/ > >
