On Aug 14, 2011, at 12:55 PM, Paul Davis wrote:
> My plan was to rewrite couch.js to use the new request/response
> classes internally and then when we need closer HTTP access we'd be
> able to have it. Same for T and Tequals. and what not. There is at
> least one test that we just can't make work in our current couchjs
> based test runner because it needs to use async HTTP requests, so at a
> certain point we have to at least add some of this stuff.
>
> I quite like using etap over eunit as it seems more better. Also, now
> that we're going to a second language for make check tests, it seems
> like an even better approach. Though I'm not at all married to it by
> any means. Also, I do understand your concerns about moving parts and
That's fine with me, I'm not impressed with etap but it seems to have worked
out well so far. By
moving parts I mean the usual thing: the more moving parts, third party libs,
etc. the more things
to get right and make work on various machines. Eunit comes bundled with OTP
> uncessesary dependencies. I should get around to updating the build
> system to use the single file etap distribution but its never really
> been a concern.
>
> Another thing I've been contemplating is if it'd be beneficial to
> remove libcurl and replace it with node.js's parser or with the ragel
> parser from Mongrel. Anyway, food for thought. I'll be around this
> afternoon to hack.
>
> On Sun, Aug 14, 2011 at 7:50 AM, Robert Dionne
> <[email protected]> wrote:
>> Paul,
>>
>> This is interesting, and if you're willing to put together the new
>> infrastructure I can help with writing tests. I would suggest a more
>> incremental approach that's less of a rewrite (rewrites often just get you
>> back to 0 from a user's perspective).
>>
>> The existing CouchDB JS object seems to work ok in terms of the http
>> interface, and the Futon tests more or less all ran using couchjs until very
>> recently. I would suggest getting these all running first, reusing copies of
>> the existing CouchDB objects and such so we can hack them as needed. Then we
>> would review and throw out all the tests that are not part of the core APIs,
>> like the coffee stuff (I don't know why we decided to bundle coffee in
>> there) and any tests that are for specific internals.
>>
>> At some point something like BigCouch is integrated in or MobileCouch we
>> might have different "make" targets for the different deployments. Perhaps
>> in that case we'd have different sets of tests. There needs to be a set of
>> tests that can verify that the semantics of API calls is the same in CouchDB
>> and BigCouch.
>>
>> So I'd say let's work backwards from what we have. Also I'm not a big fan
>> of etap, preferring eunit mainly because it's one less moving part. For JS
>> we already have this T(...) and TEquals(....) funs which seem to do the
>> trick.
>>
>> All that said, I have a few hours today to hack on this today if you want
>> some help just ping me on #couchdb
>>
>> Bob
>>
>>
>>
>>
>> On Aug 12, 2011, at 11:46 AM, Paul Davis wrote:
>>
>>> Here's a bit of a brain dump on the sort of environment I'd like to
>>> see our CLI JS tests have. If anyone has any thoughts I'd like to hear
>>> them. Otherwise I'll start hacking on this at some point over the
>>> weekend.
>>>
>>> https://gist.github.com/1142306
>>
>>
