From user-return-7405-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sat Nov 07 13:31:34 2009
Return-Path:
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: (qmail 90415 invoked from network); 7 Nov 2009 13:31:34 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 7 Nov 2009 13:31:34 -0000
Received: (qmail 87378 invoked by uid 500); 7 Nov 2009 13:31:32 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 87297 invoked by uid 500); 7 Nov 2009 13:31:32 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 87285 invoked by uid 99); 7 Nov 2009 13:31:31 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Nov 2009 13:31:31 +0000
X-ASF-Spam-Status: No, hits=-2.6 required=5.0
tests=BAYES_00
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of karel.minarik@gmail.com designates 72.14.220.157 as permitted sender)
Received: from [72.14.220.157] (HELO fg-out-1718.google.com) (72.14.220.157)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Nov 2009 13:31:28 +0000
Received: by fg-out-1718.google.com with SMTP id 22so146637fge.5
for ; Sat, 07 Nov 2009 05:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:from:to
:content-type:content-transfer-encoding:mime-version:subject:date
:x-mailer;
bh=5djFrQa4lMsBenielNRHS6KAUuGURSVWM1q0LsWBOws=;
b=ZHNiXMGd1qB/P5JFAi0wmpX0g2CVV6WSWKE7JM4aBLpbIgVkRohyJbP47IFkn3AnH9
3gqNOWtpg/n6oQTzuV0/EW7fBS1Z9H0igVDbRnD43A0Tg9vlcTzG3wuHC2Blm0W5p8Xi
uptDmWmKfOIlYgpruWZiqM0+lhWKy2yP3hd3M=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=message-id:from:to:content-type:content-transfer-encoding
:mime-version:subject:date:x-mailer;
b=KHWVkxtzmrJwjJABmBkefqaIW2nWoFJrCYwgJc2rjvwOqKjOxz2GPLpqU4W8UGZ3Oy
D/5SSbvA1WQzjosf8odg2A96wpZImarLL2gWvpKauVDqXqwWoBJdhlGV7UKVRjJOeSHc
ye3P1HpwSDsWlO0TB2ehWHJWiGW8gc1k+60lA=
Received: by 10.103.126.32 with SMTP id d32mr2180249mun.0.1257600666453;
Sat, 07 Nov 2009 05:31:06 -0800 (PST)
Received: from ?192.168.2.101? (a40-prg1-10-118.static.adsl.vol.cz [88.146.57.118])
by mx.google.com with ESMTPS id 12sm3548690muq.18.2009.11.07.05.31.05
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sat, 07 Nov 2009 05:31:05 -0800 (PST)
Message-Id: <177E2090-776A-4C2D-9BFB-89BF4F074DFB@gmail.com>
From: =?UTF-8?Q?Karel_Mina=C5=99=C3=ADk?=
To: user@couchdb.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Tests/TDD for CouchDB views
Date: Sat, 7 Nov 2009 14:31:04 +0100
X-Mailer: Apple Mail (2.936)
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