Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 74.125.44.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=A76ZqfHB9WFAGb0uCe1PDo3sSJA7CEjNYow7fjLUt97iZJOK/Iqm2IVzFuxr29S/Ef
         Rx1Fu95HynuckeuvDLD8PP5ETV+TtjsjX5TScTb6stlJquzy+v7TRlyRMblshFzjXLv8
         E4aaDR/xwGSY/gfovBCMOMisr+m173TIq/f1I=
MIME-Version: 1.0
In-Reply-To: <A9A10A46-5BD9-4168-AE8C-91A73EB62E7F@gmail.com>
References: <D574CA7F-2441-4342-9382-1AD8A20395EB@apache.org>
	 <e2111bbb0902131030q776b5a4fje5f8230286aa4884@mail.gmail.com>
	 <D842C6B0-38D3-4A43-AB19-05A8B7877DD1@gmail.com>
	 <e2111bbb0902131539u79815800o8f9c482ef8153edf@mail.gmail.com>
	 <A9A10A46-5BD9-4168-AE8C-91A73EB62E7F@gmail.com>
Date: Fri, 13 Feb 2009 19:13:20 -0500
Message-ID: <e2111bbb0902131613x4a16565ema68a3f594617546a@mail.gmail.com>
Subject: Re: Ideas for Changes to the Test Suite
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Fri, Feb 13, 2009 at 6:55 PM, Antony Blakey <antony.blakey@gmail.com> wrote:
>
> On 14/02/2009, at 10:09 AM, Paul Davis wrote:
>
>> Tests should be identifiable obviously, but if you want literature in
>> your code, go write AppleScript.
>
> Code should prioritize easy comprehensibility, especially given that there's
> no separate documentation. You're obviously not a literate programming fan
> :)
>

If the intention of the code is clear then why bother repeating the
intention, why bother repeating the intention when the code is clear?
See, its fucked up. If you need to point out something subtle, then
use a comment.

> And if you want terseness, got write APL - I did that for two years, and
> it's a heap of fun.
>
>>> Our requirements are a working HTTP client implementation, and a
>>> browser's
>>> conformance to that isn't about it's Couch support. I think this should
>>> be a
>>> separate project.
>>
>> I'm confused by the the argument that we should treat in browser tests
>> differently for a vote against treating in-browser tests differently.
>
> We shouldn't have in-browser tests. In-browser tests are about testing the
> browser, which we shouldn't do in this project. Our tests should be about
> Couch, on the command-line, build-farm-integratable.
>
> If those tests are also runnable from the browser, just for chuckles, then
> fine, but that's not the canonical environment because it introduces another
> variable into the mix.
>

The scheme I was suggesting was keeping around a small set of tests to
check browser compliance with JS funcitonality that CouchDB requires.
Things like making sure your XHR can do DELETE's (which is a bug in
Opera we've run into).

Otherwise I think we're in total agreement.

> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> He who would make his own liberty secure, must guard even his enemy from
> repression.
>  -- Thomas Paine
>
>
>

HTH,
Paul Davis