couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Tests/TDD for CouchDB views
Date Tue, 10 Nov 2009 20:23:51 GMT
On Tue, Nov 10, 2009 at 11:44:27AM +0100, Karel Minařík 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  
>> tests. That
>> is, you ...
>
> of course, it is not different *in principle* at all. I am specifically 
> curious about concrete strategies/techniques/best practices or ways *how* 
> to do it. Eg., Jan has a fixture directly in the design document: how 
> 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 = DB('test')
      @db.recreate_database!
      @foos = Foo.on(@db)
      @foos.create!(...)
      @foos.create!(...)
      @foos.create!(...)
      @foos.create!(...)
    end

    should "reduce across range" do
      res = @foos.view "by_bar", :reduce=>true,
             :startkey=>...,
             :endkey=>...
      assert_equal [{
        "key"=>nil,
        "value"=>{
          "count"=>2,
          "min_flurble"=>...,
          "max_flurble"=>...,
        }
      }], 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 could
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 suitable
data to exercise re-reduce properly, or be sure you've covered them properly)

> So I am not convinced that tying the view tests/development/generation  
> 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 CouchApp
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.

Mime
View raw message