Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 182508FDA for ; Sun, 14 Aug 2011 16:56:50 +0000 (UTC) Received: (qmail 7242 invoked by uid 500); 14 Aug 2011 16:56:49 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 7113 invoked by uid 500); 14 Aug 2011 16:56:48 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 7105 invoked by uid 99); 14 Aug 2011 16:56:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Aug 2011 16:56:48 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.212.52 as permitted sender) Received: from [209.85.212.52] (HELO mail-vw0-f52.google.com) (209.85.212.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Aug 2011 16:56:44 +0000 Received: by vws16 with SMTP id 16so5302415vws.11 for ; Sun, 14 Aug 2011 09:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=U7bu8RkgNd9TmLSx7nA6s8ihicKgKwccwhWvIx+hr5s=; b=opEWDexvGL7mQ02Iai0aM2bKsV+wlGKCJFLSSKlbuayLTZ3XSJv6IR4/v29nojFXa1 PxaDlxqtCCdBHMvDIhmMZ8IhWCUn1TcLyV9CbJ2aiMnNSmhjDC4k7iTyhwbP96ZTRBsb X5Zw64YlBQjLVZqAb4ZkqWszdmLFtlUaGocwM= Received: by 10.52.182.164 with SMTP id ef4mr3268691vdc.319.1313340983237; Sun, 14 Aug 2011 09:56:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.166.67 with HTTP; Sun, 14 Aug 2011 09:55:43 -0700 (PDT) In-Reply-To: <0E1FA99D-744A-4501-BBF9-5F29CB9D7F12@dionne-associates.com> References: <0E1FA99D-744A-4501-BBF9-5F29CB9D7F12@dionne-associates.com> From: Paul Davis Date: Sun, 14 Aug 2011 11:55:43 -0500 Message-ID: Subject: Re: Futon Test Suite To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 wrote: > Paul, > > =A0This is interesting, and if you're willing to put together the new inf= rastructure I can help with writing tests. I would suggest a more increment= al approach that's less of a rewrite (rewrites often just get you back to 0= from a user's perspective). > > =A0 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 ver= y 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. Th= en we would review and throw out all the tests that are not part of the cor= e 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. > > =A0 At some point something like BigCouch is integrated in or MobileCouch= we might have different "make" targets for the different deployments. Perh= aps 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 Co= uchDB and BigCouch. > > =A0So 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. > > =A0 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 > >