unit testing view/show functions

[Thomas Vander Stichele <th...@apestaart.org>]

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/

Re: unit testing view/show functions

[Roger Binns <ro...@rogerbinns.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Vander Stichele wrote:
> The bad part currently is that I have a lot of friction when trying to
> write view/show functions.

Agreed.  For debugging, I think it is possible to serve up the view/show
code from the server (or possibly have Futon suck it down client side) and
then run that code under Firebug with just enough scaffolding to download
the needed documents.

I did propose this on the dev list.  I don't know enough about client side
Javascript to know if Futon can suck down the view/show code and contrive a
document good enough for Firebug or if the code has to be served up from the
server.

http://mail-archives.apache.org/mod_mbox/couchdb-dev/200912.mbox/browser

Worst case I'll get around to writing a Python web "proxy" that provides the
code in a form sufficient for Firebug.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks32F0ACgkQmOOfHg372QTIKACgukitHPIwYvocGqflQGvvYPdM
fdEAniWRQW30cXHObq1vA61X93W44TAW
=Fxex
-----END PGP SIGNATURE-----

Re: unit testing view/show functions

[Alexander Lang <al...@upstream-berlin.com>]

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/
> 
> 

Re: unit testing view/show functions

[Chris Anderson <jc...@apache.org>]

On Sun, Dec 27, 2009 at 11:09 AM, Thomas Vander Stichele
<th...@apestaart.org> 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.
>

What version of CouchDB are you using? I recently checked some work
into trunk which should fix most of these problems, and I'd be curious
to know if it helps in your case.

As far as unit testing, it is possible to use CouchDB's JS test
framework with custom test files.

Don't run this test in Safari! Actually, I don't think it works at
all, but looking at the code should show you how to make your own
tests that use the Futon test runner.

http://jchrisa.net/_utils/couch_tests.html?/drl/_design/sofa/tests.js

I've actually had better luck using cucumber and rspec for this stuff,
but I've got a Ruby background, so that makes sense to me. I'd be
happy to hear what others are doing.

Chris


-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Re: unit testing view/show functions

[Matteo Caprari <ma...@gmail.com>]

I have the very same problems with latest trunk version.

During developement I have the habit to wrap my code with try {}
catch(e) { log(e) } to avoid the misery of that lot of unreadable
outptut and crashes
that untrapped exceptions tend to cause. I also use plenty of log().
It's probably the least elegant solution, but it works.

I'd welcome a debugger of sorts or integration with firebug, but I
think the root problem is that the environment is not forgiving enough
of errors.

-teo

On Sun, Dec 27, 2009 at 7:09 PM, Thomas Vander Stichele
<th...@apestaart.org> 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/
>
>
>



-- 
:Matteo Caprari
matteo.caprari@gmail.com