incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karel Minařík <karel.mina...@gmail.com>
Subject Re: Tests/TDD for CouchDB views
Date Tue, 10 Nov 2009 10:44:27 GMT
Hello,

On 7.Nov, 2009, at 22:58 , Brian Candler 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?

>> * 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?
> I do the latter (using my own CouchTiny rather than CouchRest). Your  
> views
> are source-controlled together with the rest of your application, your
> application can populate the design docs when required, and you can
> integrate your view tests with your application tests just as you  
> wish.

Yes, that's one way of thinking about this. But, in fact, when I am  
thinking about "mental shifts" Couch brings to my RDBMS-based  
experience, I don't think it's the one ot the best way. In a standard  
Rails app, for example, database is *usually* (please note emphasis)  
just dumb storage for data. You model the domain, manage validations,  
etc in your application code.

With Couch, as I see it, it would make much more sense to "de-couple"  
the database from the application. First, "my" app is not neccessarily  
the only one working with the database, given MVCC/replication/ 
standalone couchapps/etc. (And that I tend to see as good and awesome  
thing.) Second, Couch provides relatively rich functionality without  
any "middleware" -- think polling the _changes API or the _update  
hooks. My knowledge here is severely limited, but this seems to me  
like a big (and, again, awesome) difference to the usual ways.

So I am not convinced that tying the view tests/development/generation  
to the app is neccessarily the best way. That's why I was asking about  
concrete strategies, because I couldn't find almost *any*  
documentation on this.

>> * Is there a way to automatically run such test suites? (Via  
>> browser, or
>> something like Rhino?)
> Same.

Sure: again, I am sorry, but was asking about some specific, real- 
world info. After some investigation, using couchjs for running the JS  
code would be much better fit. But, is there any info/tutorial?

> ou can set up 'test', 'development' and 'production' environments for
> CouchDB just as ActiveRecord does, and this is how I handle it. See
> http://github.com/candlerb/couchtiny/blob/master/doc/RAILS.rdoc

Thanks for the link! So, you basically declare the view JS code in  
your model (`define_view "Foo_by_bar"`) and let CouchTiny upload it to  
the database? While I see the point here, I would rather not tie views  
to the application code in this way (as said above). But, again, I  
might be seriously mistaken about this.

I would highly appreciate any info, or just opinion/perspective on  
this...

Best,

Karel



Mime
View raw message