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