couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Futon Test Suite
Date Mon, 15 Aug 2011 14:41:17 GMT
Not sure I follow what you mean there. When I mentioned node's HTTP
parser, I meant, the parser [1]. I'd still have to write my own C
adaptor for that to Spidermonkey objects. Not entirely certain on the
REPL bit, but couchjs was basically a hack on top of the Spidermonkey
js REPL so going back to our roots a bit there shouldn't be too hard.

[1] https://github.com/ry/http-parser

On Mon, Aug 15, 2011 at 8:38 AM, Adam Kocoloski <kocolosk@apache.org> wrote:
> I thought about suggesting node's parser, especially since you'd get the REPL for free.
 I think the downside is that there are roughly 300 versions of node out there, and I'd hate
for our tests to keep breaking because of node's development pace.  libcurl is nothing if
not stable.
>
> Adam
>
> 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
>> 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
>> <dionne@dionne-associates.com> 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
>>>
>>>
>
>

Mime
View raw message