Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of b.candler@pobox.com
 designates 64.74.157.62 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to:cc
	:subject:message-id:references:mime-version:content-type
	:in-reply-to:content-transfer-encoding; q=dns; s=sasl; b=fRkYUde
	twaVg5kuFiEj1oU3SZn2hk83Y5OZlVvPDOuO9kE2KFIKw/vNyxt2gYWZDC+jd8F+
	MAqnvVYXnVPbLEicIQo4s6yQLyzFqauT+TWtrPkGDZKQyLckwmSka1EJ+CkLpX/x
	n/bZpkKljn5zAQvOUkdg8lxmeC9APKKLHmOQ=
Date: Tue, 10 Nov 2009 20:23:51 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Karel =?utf-8?B?TWluYcWZw61r?= <karel.minarik@gmail.com>
Cc: user@couchdb.apache.org
Subject: Re: Tests/TDD for CouchDB views
Message-ID: <20091110202351.GC18411@uk.tiscali.com>
Mail-Followup-To: Karel =?utf-8?B?TWluYcWZw61r?= <karel.minarik@gmail.com>,
 user@couchdb.apache.org
References: <5B348DFD-D44B-48F2-8438-2F5FD63F9317@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5B348DFD-D44B-48F2-8438-2F5FD63F9317@gmail.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 10, 2009 at 11:44:27AM +0100, Karel Mina=C5=99=C3=ADk wrote:
>>> * How do would you write/implement tests for your views?
>> I don't see in principle why it can't be any different to normal =20
>> tests. That
>> is, you ...
>
> of course, it is not different *in principle* at all. I am specifically=
=20
> curious about concrete strategies/techniques/best practices or ways *ho=
w*=20
> to do it. Eg., Jan has a fixture directly in the design document: how=20
> does one work with it then? Is this a good way to TDD views?

I tend to steer away from static fixtures, but populate the DB directly
within tests.

Digging through some code, I note I have a complex view and unit tests
exactly as you're describing. The tests look like this:

class FooTest < Test::Unit::TestCase
  context "bar_view" do
    setup do
      @db =3D DB('test')
      @db.recreate_database!
      @foos =3D Foo.on(@db)
      @foos.create!(...)
      @foos.create!(...)
      @foos.create!(...)
      @foos.create!(...)
    end

    should "reduce across range" do
      res =3D @foos.view "by_bar", :reduce=3D>true,
             :startkey=3D>...,
             :endkey=3D>...
      assert_equal [{
        "key"=3D>nil,
        "value"=3D>{
          "count"=3D>2,
          "min_flurble"=3D>...,
          "max_flurble"=3D>...,
        }
      }], res
    end
  end

So this test is basically the same as a typical functional test:
- put the database into a known state
- do something (query the view)
- check the result

It certainly could be interesting to test at a more "unit" level. You cou=
ld
fire up the js view server, stuff some documents into it, and check the
values emitted. But I think it would get fairly icky testing reduce and
re-reduce functions this way. (OTOH, it's not always easy to set up suita=
ble
data to exercise re-reduce properly, or be sure you've covered them prope=
rly)

> So I am not convinced that tying the view tests/development/generation =
=20
> to the app is neccessarily the best way.

If you want to deploy your views separately to any "app" using them, then=
 I
agree with you that it makes sense to test them separately. Perhaps Couch=
App
could have a little framework for this.

There are much more than views which you might want to test of course - e=
.g.
validate_doc_update functions, _show and _list.

Regards,

Brian.