Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of gurdiga@gmail.com designates
 216.239.58.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=bx6fAFHQFEoKhlkKFL1VaLJI4+oHl66J0CLH2/RGg+PwGwhNuGun4Itr53FeGNAG93
         w045GvtV7pXHrJcLuHC58UUQHhMx6X7mX4ykSMaamkQlB/1mtPFo5MahCy+vhNxPEJ8P
         OEH0wCJZCYxfmbzdwvUCBsrP/rDgZcdLSOnNk=
MIME-Version: 1.0
From: Vlad GURDIGA <gurdiga@gmail.com>
Date: Tue, 3 Nov 2009 14:05:32 +0200
Message-ID: <da7069940911030405v220bab17i8799821d9995210e@mail.gmail.com>
Subject: Testing shows and lists
To: couchdb-user@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

Hello!

How would someone test the application code inside shows and lists? Is
there any recommended way or some best-practice?

The actual page is probably more practical to test inside the browser
with something like QUnit. But, before uploading the show to CouchDB
I'd like to make sure it does not throw syntactical or other errors
like undefined variable/function/whatever.

If you get it to CouchDB in an "unstable" state it's pretty
uncomfortable to find what's broken even from the logs when you have a
page built up from more than a couple page components (with CouchApp
macro-instructions like // !code and // !json).

You can TDD the code you use all over the application by separating it
into a library*. But how would you make sure that the page components
and the other code that build up the page do actually glue up together
nicely before uploading it?

* http://github.com/gurdiga/cozy/tree/master/lib/

Why before? Because it is an earlier feedback, and it is probably *a
lot* faster to run it from command line with SpiderMonkey.

Now,if you feed the show, which is an anonymous function to js, it
only checks for syntactic correctness, because it does not actually
run that function. You can try to kinda monkey-patch the function by
adding "(" before and ")()" after the function body with a little
shell script like this:

#!/bin/sh

echo "("
cat $1
echo ")();"

and then use it like:

$ ./mokey-patch.sh ./shows/page.js | js -w -s

This way you would have that function ran and you'd find out that you
need to mock up the "doc" and "req" variables if you have references
to them in your code.

When it comes to lists you get one more layer to penetrate: the code
that you'll write is given as a closure to the "provides" function,
and running the main list function with js does not actually run the
code in the closure unless you will try to import somehow the original
"provides" function from the CouchDB code, which seamed kinda scary to
me and I abandoned this idea.

The way which I ended up with was to kinda "export" the application
code into a separate file named like "page.app.js" in which I have all
my application code and which I inject back to the show file before
"couchapp push" to CouchDB. Having it separate gives me the ability to
make sure it runs before I get it on-line. Of course I have to fake
all the data I get as arguments to the main function, but this turned
out not to be that hard*.

* http://github.com/gurdiga/cozy/blob/master/shows/book.app.js#L1

The bad thing about my "approach" is that I get almost *twice as much
code* uploaded to CouchDB as is actually ran by the show/list because
the *.app.js is preprocessed by CouchApp and all the "// !code" macros
are expanded.

It is functional, it works, but it does not feel quite right. =(

I'm kinda stuck here for now, so any good ideas are welcome. :)