Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of dionne@dionne-associates.com
 designates 67.222.54.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;
 d=dionne-associates.com;
	h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-Identified-User;
	b=dCcOwHqax5tVQsuHDiol6GhZxEOdWHnkjdEvD9HFJcmR9HkAq00z479Qa65jM7TjgJS8i+coEjqU5OsQRZ/DdLDcL4AgKwaUjNuow7si5supeIidbDZMRKJxcffAsprL;
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <1F552D0F-A893-49E4-BC1D-1E0743410E50@apache.org>
References: <52FC71A1-9758-47CE-B8BE-79F5D704B867@apache.org>
 <83A73DE5-5405-4B42-B335-8A25DB4A9AEF@apache.org>
 <4001C44E-C9FE-4643-821C-7C979E929D8E@apache.org>
 <E4300EC7-B162-4CBC-A93A-B5E3440DE653@dionne-associates.com>
 <3A88CA1A-DE67-465A-BE7C-63CEF50DC57E@apache.org>
 <C1BBB57E-B8D1-4A22-B76D-C5D8F88FF3CE@dionne-associates.com>
 <944EE9A7-FA9E-4947-BF80-00A501B619E3@apache.org>
 <30FBC068-299C-47A6-ADAA-A5437AF05F22@dionne-associates.com>
 <1F552D0F-A893-49E4-BC1D-1E0743410E50@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7A46294D-5667-4D99-AE51-4D0E526BCBFD@dionne-associates.com>
Content-Transfer-Encoding: 7bit
From: Robert Dionne <dionne@dionne-associates.com>
Subject: Re: [PATCH] Eunit Tests
Date: Mon, 16 Feb 2009 09:36:40 -0500
To: dev@couchdb.apache.org


On Feb 16, 2009, at 8:03 AM, Jan Lehnardt wrote:

>
> On 16 Feb 2009, at 13:37, Robert Dionne wrote:
>
>>> Pure unit-test logic would suggest creating a couch_btree_chunker
>>> module. Like how I did with couch_config and couch_config_writer.
>>> But then, pragmatism will call heresy and I'd probably agree.
>>
>> For sure, "In theory there's no difference between theory and  
>> practice, but in practice there is"  :)
>
> The question is if we want to "do it right" now or KISS our way out  
> of this?
>
>
>>> The only problem I see here is that tests belonging to a single  
>>> module
>>> are run in different places and you'd have to track down where  
>>> the test
>>
>>  hmm... actually according to the docs if you run eunit:test 
>> ([couch_btree])  it does both (I haven't tested this yet). In  
>> other words it ensures couch_btree:test() is run and also finds  
>> and runs tests in couch_btree_tests. So if I read this correctly  
>> it solve this issue, non?
>
> You're right, I just tested this, nice.
>
>
>> Oh I see, it wouldn't tell you which ones failed?
>
> No no, it does. All is well :)
>
>
> I'd suggest we establish this guidelines for writing tests:
>
>  - A module's public API should be tested in a separate module as  
> it helps
>    refining the public API, keeps files at a manageable size and  
> changes
>    to either tests or the module don't interfere with each other  
> (plus all the
>    good thing Michael McDaniel pointed out earlier).
>
>  - A module's private API is tested using inline-tests.
>
>  - Large* modules should be considered for split-ups keep things more
>    manageable.
>
> *Large is defined pragmatically on a case-by-case basis.
>
>
> What do you think?

+1 (if I get a vote :)

I agree completely. As I count the files in src/couchdb (32 and  
growing) I think it's a good time to start this, even if new tests  
are only added opportunistically as bugs are fixed, etc... When 1.0  
comes along and larger new features added these will serve us well.  
Danke vielmals!


>
> Cheers
> Jan
> --
>