Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 66493 invoked from network); 12 Oct 2005 16:55:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Oct 2005 16:55:24 -0000 Received: (qmail 18342 invoked by uid 500); 12 Oct 2005 16:55:23 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 18289 invoked by uid 500); 12 Oct 2005 16:55:23 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 18277 invoked by uid 99); 12 Oct 2005 16:55:23 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 09:55:23 -0700 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.202 as permitted sender) Received: from [64.233.184.202] (HELO wproxy.gmail.com) (64.233.184.202) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 09:55:25 -0700 Received: by wproxy.gmail.com with SMTP id i21so51975wra for ; Wed, 12 Oct 2005 09:54:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=LWgEN0rZnxA9Da8yjxrtN8IWyjlpphOkVD+unCotQx6IrRzg2eQqyvMEaWDdNf+/rPg/yIBR8hsvQ0RN9VVLAgiMQvqogcmk3HMHMPVVDjv7OYrCfsjIVlPCFvoJwv4C0dBgi8lj7FNJSqZ9XMA/6sc04j8oS4A+34JSNOm3hjg= Received: by 10.54.86.6 with SMTP id j6mr209161wrb; Wed, 12 Oct 2005 09:54:59 -0700 (PDT) Received: by 10.54.71.11 with HTTP; Wed, 12 Oct 2005 09:54:59 -0700 (PDT) Message-ID: <768dcb2e0510120954h66345b1dx@mail.gmail.com> Date: Thu, 13 Oct 2005 01:54:59 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398) In-Reply-To: <434D39D7.7030001@bellsouth.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15628_24375467.1129136099373" References: <20051009111642.39226.qmail@minotaur.apache.org> <434BF069.90203@bellsouth.net> <1129051646.8090.73.camel@portable> <434BF751.1010005@bellsouth.net> <1129055907.13190.2.camel@wkslx01.iktek.com> <434C1508.4070800@bellsouth.net> <768dcb2e0510111730r77c1e298m@mail.gmail.com> <434C6117.1000501@bellsouth.net> <768dcb2e0510120918n4719d12eg@mail.gmail.com> <434D39D7.7030001@bellsouth.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_15628_24375467.1129136099373 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2005/10/13, Alex Karasulu : > > Trustin Lee wrote: > > > 2005/10/12, Alex Karasulu > >: > > > > Trustin Lee wrote: > > > > > The essential problem in our project is that our tests are not unit > > > tests. If we're doing unit tests, we don't need to start up the > > whole > > > ApacheDS everytime we test each classes. But we're doing so by > > some > > > reason and the tests takes too much time. Ideally we should change > > > all of them to unit tests strictly speaking. > > > > You're right these are more *integration* tests and not simple unit > > tests. Again correctness is not always the most sensible approach in > > our present not so perfect situation :). > > > > It's very hard to unit test these interceptors properly though because > > many presume access to the core. I see how you performed unit > > tests on > > the ACI code but I think this was a special case. Without a > > harness you > > cannot really test an interceptor. > > > > > > Once we implement in-memory DirectoryPartition (formerly > > ContextPArtition) implementation, then we can implement mock > > NextInterceptor very easily which is the hardest part. Nothing is > > different in this case. > > > > So what you're suggesting is we move these tests to an apacheds test > > project? Hmmm ... That would mean we don't have to create the extra > > maven projects since there would be no dep in core and in main for > > these > > abstract testcases. I like the sound of this, but it raises some > > concerns for me. I kind of like the fact that nothing deploys unless > > those tests pass even though it takes a long time for them to run. > > > > > > Yes. But this doesn't necessarily mean that we have to run integration > > test for *every* test case just like now. We can create a single > > integration test that tries to launch ApacheDS with full set of > > interceptors and to test basic LDAP operations. If the core still has > > some issues, then it's a bug of our test code primarily so I cannot > > believe the integration test helps us to test individual interceptors. > > I don't know what you're talking about now. Sorry I'm lost. What I'm pointing out are two: 1) We can write unit test for most interceptors and if we can't, it means we've got some design problem which means that our code is tightly coupled to each other that leads to the integration which hinders unit testing. 2) For now all interceptor tests are integration tests, so it takes more than a minute to run whole tests. We don't have to do this only if we have proper unit tests. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_15628_24375467.1129136099373 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
2005/10/13, Alex Karasulu <aok123@bellsouth.net>: Trustin Lee wrote:

> 2005/10/12, Alex Karasulu <aok123@bellsouth.net
> <mailto:aok123@bellsouth.net>>:
>= ;
>     Trustin Lee wrote:
>
> &n= bsp;   > The essential problem in our project is that our test= s are not unit
>     > tests.  If we= 're doing unit tests, we don't need to start up the
>  &nbs= p;  whole
>     > ApacheDS everytime we test each class= es.  But we're doing so by
>     some>     > reason and the tests takes too much tim= e.  Ideally we should change
>     >= all of them to unit tests strictly speaking.
>
>     You're right these are more *integ= ration* tests and not simple unit
>     tests.&nb= sp; Again correctness is not always the most sensible approach in
&= gt;     our present not so perfect situation :).
>
>     It's very hard to unit test these = interceptors properly though because
>     many p= resume access to the core.  I see how you performed unit
>&= nbsp;    tests on
>     the ACI co= de but I think this was a special case.  Without a
>     harness you
>    = ; cannot really test an interceptor.
>
>
> Once we implem= ent in-memory DirectoryPartition (formerly
> ContextPArtition) implem= entation, then we can implement mock
> NextInterceptor very easily which is the hardest part.  = Nothing is
> different in this case.
>
>   = ;  So what you're suggesting is we move these tests to an apacheds tes= t
>     project?  Hmmm ... That would m= ean we don't have to create the extra
>     maven projects since there would be no dep= in core and in main for
>     these
> = ;    abstract testcases.  I like the sound of this= , but it raises some
>     concerns for me. I kin= d of like the fact that nothing deploys unless
>     those tests pass even though it takes a lo= ng time for them to run.
>
>
> Yes. But this doesn't nece= ssarily mean that we have to run integration
> test for *every* test = case just like now.  We can create a single
> integration test that tries to launch ApacheDS with full set of> interceptors and to test basic LDAP operations.  If the cor= e still has
> some issues, then it's a bug of our test code primarily= so I cannot
> believe the integration test helps us to test individual intercept= ors.

I don't know what you're talking about now.   Sorry I= 'm lost.

What I'm pointing out are two:
1) We can write unit test for most interceptors and if we can't, it me= ans we've got some design problem which means that our code is tightly coup= led to each other that leads to the integration which hinders unit testing.

2) For now all interceptor tests are integration tests, so it takes= more than a minute to run whole tests.  We don't have to do this only= if we have proper unit tests.

Trustin
--
what we call human = nature is actually human habit
--
http://gleamynode.net/ ------=_Part_15628_24375467.1129136099373--