You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by el...@apache.org on 2005/10/09 13:16:41 UTC

svn commit: r307398 - in /directory/apacheds/trunk/core/src/test/org/apache/ldap/server: AbstractAdminTestCase.java AbstractNonAdminTestCase.java AbstractTestCase.java

Author: elecharny
Date: Sun Oct  9 04:16:35 2005
New Revision: 307398

URL: http://svn.apache.org/viewcvs?rev=307398&view=rev
Log:
moved those three classes from the src/java directory to src/test directory

Added:
    directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractAdminTestCase.java
    directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractNonAdminTestCase.java
    directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractTestCase.java

Added: directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractAdminTestCase.java
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractAdminTestCase.java?rev=307398&view=auto
==============================================================================
--- directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractAdminTestCase.java (added)
+++ directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractAdminTestCase.java Sun Oct  9 04:16:35 2005
@@ -0,0 +1,32 @@
+/*
+ *   Copyright 2004 The Apache Software Foundation
+ *
+ *   Licensed under the Apache License, Version 2.0 (the "License");
+ *   you may not use this file except in compliance with the License.
+ *   You may obtain a copy of the License at
+ *
+ *       http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *   Unless required by applicable law or agreed to in writing, software
+ *   distributed under the License is distributed on an "AS IS" BASIS,
+ *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *   See the License for the specific language governing permissions and
+ *   limitations under the License.
+ *
+ */
+package org.apache.ldap.server;
+
+
+/**
+ * A simple testcase for testing JNDI provider functionality.
+ *
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ * @version $Rev: 190555 $
+ */
+public abstract class AbstractAdminTestCase extends AbstractTestCase
+{
+    protected AbstractAdminTestCase()
+    {
+        super( "uid=admin,ou=system", "secret" );
+    }
+}

Added: directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractNonAdminTestCase.java
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractNonAdminTestCase.java?rev=307398&view=auto
==============================================================================
--- directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractNonAdminTestCase.java (added)
+++ directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractNonAdminTestCase.java Sun Oct  9 04:16:35 2005
@@ -0,0 +1,34 @@
+/*
+ *   Copyright 2004 The Apache Software Foundation
+ *
+ *   Licensed under the Apache License, Version 2.0 (the "License");
+ *   you may not use this file except in compliance with the License.
+ *   You may obtain a copy of the License at
+ *
+ *       http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *   Unless required by applicable law or agreed to in writing, software
+ *   distributed under the License is distributed on an "AS IS" BASIS,
+ *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *   See the License for the specific language governing permissions and
+ *   limitations under the License.
+ *
+ */
+package org.apache.ldap.server;
+
+
+
+
+/**
+ * Adds extra code to perform operations as another user besides the admin user.
+ *
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ * @version $Rev: 190555 $
+ */
+public abstract class AbstractNonAdminTestCase extends AbstractTestCase
+{
+    protected AbstractNonAdminTestCase()
+    {
+        super( "uid=akarasulu,ou=users,ou=system", "test" );
+    }
+}

Added: directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractTestCase.java
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractTestCase.java?rev=307398&view=auto
==============================================================================
--- directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractTestCase.java (added)
+++ directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractTestCase.java Sun Oct  9 04:16:35 2005
@@ -0,0 +1,338 @@
+/*
+ *   Copyright 2004 The Apache Software Foundation
+ *
+ *   Licensed under the Apache License, Version 2.0 (the "License");
+ *   you may not use this file except in compliance with the License.
+ *   You may obtain a copy of the License at
+ *
+ *       http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *   Unless required by applicable law or agreed to in writing, software
+ *   distributed under the License is distributed on an "AS IS" BASIS,
+ *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *   See the License for the specific language governing permissions and
+ *   limitations under the License.
+ *
+ */
+package org.apache.ldap.server;
+
+
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileNotFoundException;
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.ArrayList;
+import java.util.Hashtable;
+import java.util.List;
+
+import javax.naming.Context;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
+import javax.naming.directory.Attributes;
+import javax.naming.ldap.InitialLdapContext;
+import javax.naming.ldap.LdapContext;
+
+import junit.framework.TestCase;
+
+import org.apache.commons.io.FileUtils;
+import org.apache.commons.lang.exception.NestableRuntimeException;
+import org.apache.ldap.common.ldif.LdifIterator;
+import org.apache.ldap.common.ldif.LdifParserImpl;
+import org.apache.ldap.common.message.LockableAttributesImpl;
+import org.apache.ldap.server.configuration.Configuration;
+import org.apache.ldap.server.configuration.MutableStartupConfiguration;
+import org.apache.ldap.server.configuration.ShutdownConfiguration;
+
+                                                                                                            
+/**
+ * A simple testcase for testing JNDI provider functionality.
+ *
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ * @version $Rev: 280870 $
+ */
+public abstract class AbstractTestCase extends TestCase
+{
+    public static final String LDIF = "dn: uid=akarasulu,ou=users,ou=system\n" +
+            "cn: Alex Karasulu\n" +
+            "sn: Karasulu\n" +
+            "givenname: Alex\n" +
+            "objectclass: top\n" +
+            "objectclass: person\n" +
+            "objectclass: organizationalPerson\n" +
+            "objectclass: inetOrgPerson\n" +
+            "ou: Engineering\n" +
+            "ou: People\n" +
+            "l: Bogusville\n" +
+            "uid: akarasulu\n" +
+            "mail: akarasulu@apache.org\n" +
+            "telephonenumber: +1 408 555 4798\n" +
+            "facsimiletelephonenumber: +1 408 555 9751\n" +
+            "roomnumber: 4612\n" +
+            "userpassword: test\n";
+    
+    private final String username;
+    
+    private final String password;
+
+    /** the context root for the system partition */
+    protected LdapContext sysRoot;
+    
+    /** flag whether to delete database files for each test or not */
+    protected boolean doDelete = true;
+    
+    protected MutableStartupConfiguration configuration = new MutableStartupConfiguration();
+
+    /** A testEntries of entries as Attributes to add to the DIT for testing */
+    protected List testEntries = new ArrayList();
+
+    /** An optional LDIF file path if set and present is read to add more test entries */
+    private String ldifPath;
+
+    /** Load resources relative to this class */
+    private Class loadClass;
+
+    private Hashtable overrides = new Hashtable(); 
+
+    protected AbstractTestCase( String username, String password )
+    {
+        if( username == null || password == null )
+        {
+            throw new NullPointerException();
+        }
+
+        this.username = username;
+        this.password = password;
+    }
+
+    /**
+     * Sets the LDIF path as a relative resource path to use with the
+     * loadClass parameter to load the resource.
+     *
+     * @param ldifPath the relative resource path to the LDIF file
+     * @param loadClass the class used to load the LDIF as a resource stream
+     */
+    protected void setLdifPath( String ldifPath, Class loadClass )
+    {
+        this.loadClass = loadClass;
+
+        this.ldifPath = ldifPath;
+    }
+
+
+    /**
+     * Sets the LDIF path to use.  If the path is relative to this class then it
+     * is first tested
+     *
+     * @param ldifPath the path to the LDIF file
+     */
+    protected void setLdifPath( String ldifPath )
+    {
+        this.ldifPath = ldifPath;
+    }
+
+
+    /**
+     * Get's the initial context factory for the provider's ou=system context
+     * root.
+     *
+     * @see junit.framework.TestCase#setUp()
+     */
+    protected void setUp() throws Exception
+    {
+        super.setUp();
+
+        // -------------------------------------------------------------------
+        // Add a single test entry
+        // -------------------------------------------------------------------
+
+        Attributes attributes = new LockableAttributesImpl();
+
+        LdifParserImpl parser = new LdifParserImpl();
+
+        try
+        {
+            parser.parse( attributes, LDIF );
+        }
+        catch ( NamingException e )
+        {
+            throw new NestableRuntimeException( e );
+        }
+
+        testEntries.add( attributes );
+
+        // -------------------------------------------------------------------
+        // Add more from an optional LDIF file if they exist
+        // -------------------------------------------------------------------
+
+        InputStream in = null;
+
+        if ( loadClass == null && ldifPath != null )
+        {
+            File ldifFile = new File( ldifPath );
+
+            if ( ldifFile.exists() )
+            {
+                in = new FileInputStream( ldifPath );
+            }
+            else
+            {
+                in = getClass().getResourceAsStream( ldifPath );
+            }
+
+            throw new FileNotFoundException( ldifPath );
+        }
+        else if ( loadClass != null && ldifPath != null )
+        {
+            in = loadClass.getResourceAsStream( ldifPath );
+        }
+
+        if ( in != null )
+        {
+            LdifIterator list = new LdifIterator( in );
+
+            while ( list.hasNext() )
+            {
+                String ldif = ( String ) list.next();
+
+                attributes = new LockableAttributesImpl();
+
+                parser.parse( attributes, ldif );
+
+                testEntries.add( attributes );
+            }
+        }
+
+        // -------------------------------------------------------------------
+        // Add key for extra entries to the testEntries of extras
+        // -------------------------------------------------------------------
+
+        configuration.setTestEntries( testEntries );
+        doDelete( configuration.getWorkingDirectory() );
+        setSysRoot( username, password, configuration );
+    }
+
+
+    /**
+     * Deletes the Eve working directory.
+     */
+    protected void doDelete( File wkdir ) throws IOException
+    {
+        if ( doDelete )
+        {
+            if ( wkdir.exists() )
+            {
+                FileUtils.deleteDirectory( wkdir );
+            }
+            if ( wkdir.exists() )
+            {
+                throw new IOException( "Failed to delete: " + wkdir );
+            }
+        }
+    }
+
+
+    /**
+     * Sets and returns the system root.  Values of user and password used to
+     * set the respective JNDI properties.  These values can be overriden by the
+     * overrides properties.
+     *
+     * @param user the username for authenticating as this user
+     * @param passwd the password of the user
+     * @return the sysRoot context which is also set
+     * @throws NamingException if there is a failure of any kind
+     */
+    protected LdapContext setSysRoot( String user, String passwd, Configuration cfg ) throws NamingException
+    {
+        Hashtable env = new Hashtable( cfg.toJndiEnvironment() );
+        env.put( Context.SECURITY_PRINCIPAL, user );
+        env.put( Context.SECURITY_CREDENTIALS, passwd );
+        env.put( Context.SECURITY_AUTHENTICATION, "simple" );
+        return setSysRoot( env );
+    }
+
+
+    /**
+     * Sets the system root taking into account the extras and overrides
+     * properties.  In between these it sets the properties for the working
+     * directory, the provider URL and the JNDI InitialContexFactory to use.
+     *
+     * @param env an environment to use while setting up the system root.
+     * @return the sysRoot context which is also set
+     * @throws NamingException if there is a failure of any kind
+     */
+    protected LdapContext setSysRoot( Hashtable env ) throws NamingException
+    {
+        Hashtable envFinal = new Hashtable( env );
+        if ( ! envFinal.containsKey( Context.PROVIDER_URL ) )
+        {
+            envFinal.put( Context.PROVIDER_URL, "ou=system" );
+        }
+        
+        envFinal.put( Context.INITIAL_CONTEXT_FACTORY, "org.apache.ldap.server.jndi.CoreContextFactory" );
+        envFinal.putAll( overrides );
+        
+        // We have to initiate the first run as an admin at least.
+        Hashtable adminEnv = new Hashtable( envFinal );
+        adminEnv.put( Context.SECURITY_PRINCIPAL, "uid=admin,ou=system" );
+        adminEnv.put( Context.SECURITY_CREDENTIALS, "secret" );
+        adminEnv.put( Context.SECURITY_AUTHENTICATION, "simple" );
+        new InitialLdapContext( adminEnv, null );
+
+        // OK, now let's get an appropriate context.
+        return sysRoot = new InitialLdapContext( envFinal, null );
+    }
+
+    /**
+     * Overrides default JNDI environment properties.  Please call this method
+     * to override any JNDI environment properties this test case will set.
+     */
+    protected void overrideEnvironment( String key, Object value )
+    {
+        overrides.put( key, value );
+    }
+
+
+    protected Hashtable getOverriddenEnvironment()
+    {
+        return ( Hashtable ) overrides.clone();
+    }
+
+
+    /**
+     * Sets the system context root to null.
+     *
+     * @see junit.framework.TestCase#tearDown()
+     */
+    protected void tearDown() throws Exception
+    {
+        super.tearDown();
+
+        Hashtable env = new Hashtable();
+
+        env.put( Context.PROVIDER_URL, "ou=system" );
+        env.put( Context.INITIAL_CONTEXT_FACTORY, "org.apache.ldap.server.jndi.CoreContextFactory" );
+        env.putAll( new ShutdownConfiguration().toJndiEnvironment() );
+        env.put( Context.SECURITY_PRINCIPAL, "uid=admin,ou=system" );
+        env.put( Context.SECURITY_CREDENTIALS, "secret" );
+        env.put( Context.SECURITY_AUTHENTICATION, "simple" );
+
+        try { new InitialContext( env ); } catch( Exception e ) {}
+
+        sysRoot = null;
+
+        Runtime.getRuntime().gc();
+
+        testEntries.clear();
+
+        ldifPath = null;
+
+        loadClass = null;
+        
+        overrides.clear();
+        
+        configuration = new MutableStartupConfiguration();
+        
+        doDelete( configuration.getWorkingDirectory() );
+    }
+}



Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)

Posted by Emmanuel Lecharny <el...@apache.org>.
I will start from the bottom of your message :

<snip/>
> Let's not bother with 4 new maven projects.  WDYT?

YEAH ! Let's not bother with 4 more maven projects ;)

Man, you now how to talk to men : KIS, S

Ok, I rollback the change I did.

-- Emmanuel, the last S in KISS.




Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)

Posted by Trustin Lee <tr...@gmail.com>.
2005/10/13, Alex Karasulu <ao...@bellsouth.net>:
>
> Trustin Lee wrote:
>
> > 2005/10/12, Alex Karasulu <aok123@bellsouth.net
> > <ma...@bellsouth.net>>:
> >
> > 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/

Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)

Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:

> 2005/10/12, Alex Karasulu <aok123@bellsouth.net 
> <ma...@bellsouth.net>>:
>
>     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.

Alex

Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)

Posted by Trustin Lee <tr...@gmail.com>.
2005/10/12, Alex Karasulu <ao...@bellsouth.net>:
>
> 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.

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

Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)

Posted by Alex Karasulu <ao...@bellsouth.net>.
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.

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.

What else do you think we can do to make sure we protect ourselves?  
Because if we move these "integration" tests into a separate subproject 
it opens the door to the deployment of code in core and main that might 
not work.  The fact that it compiles and simple unit tests run does not 
mean the server will run.  Furthermore if we move the tests, we're going 
to have a lag before the proper unit tests are written.  Who's going to 
retrofit unit tests to all the methods.  No one is my guess.  Right now 
with these integration tests we at least have some kind of coverage to 
keep us from shooting ourselves in the foot.

WDYT?

I should not be advertising this hehe but if test execution times are an 
issue you could always bypass them on builds instead of deploys with 
this option to maven:

-Dmaven.tests.skip=true

Question is: does the fact that someone can do this to deploy artifacts 
to the remote repository make keeping these integration tests in core 
and main moot?  Probably so.  If we do remove these tests then we're 
going to need some serious protocol for managing uploads just to make 
sure these tests run and pass.

Alex


Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)

Posted by Trustin Lee <tr...@gmail.com>.
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.

I think most interceptors can be converted into unit tests just like I did
for classes in org.apache.ldap.server.authz.support package.

If we're going to create a separate testing framework project, it could be a
JndiUnit project which works for all JNDI implementations IMHO.

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

[ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)

Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:

>>>Ooops. May be a little convo on IRC could help a lot avoiding the code
>>>breaking I induced...
>>> 
>>>
>>>      
>>>
>>Let's keep this on the list.  
>>    
>>
>
>+1
>
>  
>
>>Also we *MUST* always make sure we summarize our conclusions on IRC.
>>    
>>
>
>+1 to this kind of wish
>
>  
>
>>Please don't take this Emmanuel this is more a reminder to myself :-) as 
>>well.  We neeed to watch how much info is lost on IRC now that our IRC 
>>channel's are not being logged anymore.
>>    
>>
>
>We must find a way to log those infos, and how to publish them.
>
>
>Back to the pb, what about a test-setup subproject in apacheds project?
>  
>
What do we have today?
========================

Right now apacheds has the following subprojects:

shared
core
main
plugin

Let's try to understand some of the dependencies:

main deps core
main deps shared
core deps plugin
core deps shared
plugin deps shared

The the unit testing "framework" (if you could call it that) for 
apacheds' *core* is just composed of three classes.  We're talking about 
AbstractTestCase, AbstractAdminTestCase and AbstractNonAdminTestCase.  
These test cases do not fire up the protocol providers for apacheds ... 
just the core.  This means you cannot do over the wire LDAP tests using 
the SUN JNDI Provider or with JLDAP with these TestCase base classes.  
This code just depends on the core and on shared.

In the *main* project resides another testcase base class called 
AbstractServerTest which turns on the protocols in addition to firing up 
the core.  This code depends on the main, core and shared.


Why should we separate unit test base classes?
==============================================

Now let's ask ourselves why we need to separate this stuff out from core 
and main.  I think its because we don't want these necessarily shipping 
with the core or the main since users may not be interested in unit 
testing and hence do not require those classes or the jars they depend 
on.  It thus makes sense, why, you Emmanuel, did not want these files in 
the src/main/java directory but in the src/test directory.  So 
separating them out of the core and main is a good idea.  How this is 
done or if it's worth doing is another story.

The How?
==========

Let's start first by just considering the core.  It has the 3 abstract 
test cases which must be removed however these test cases depend on core 
classes.  Core in turn depends on the test cases to drive its tests.  
This imposes a cyclic dependency.  So we cannot just separate the test 
base classes from the core.  We need to create some shared project that 
both the core and the core-unit tests depend on to break the cycle.  We 
have the same situation for the main.  In the end if we were to do this 
right then we need to create 4 new maven child projects for apacheds:

core-shared
core-unit
main-shared
main-unit

Is it worth it?
==============

IMHO it is not worth creating 4 new maven projects to get 3 classes out 
of the way.  This is the conclusion I came to 6 months ago when I had 
the idea of making this separation. 

What do I think now? Well let's not mess with this:

(1) the entropy incurred for absolute correctness is too much
(2) the unit tests are nice to have in the jar: they're just there if 
you need em
(3) the junit jar is not required as a dependency at runtime unless you 
use the base unit tests

So in the end, I actually think it becomes more convenient to leave the 
base test cases as-is in their respective src/main/java directories in 
core and main respectively.  Let's not bother with 4 new maven 
projects.  WDYT?

Alex


Re: svn commit: r307398 - in /directory/apacheds/trunk/core/src/test/org/apache/ldap/server: AbstractAdminTestCase.java AbstractNonAdminTestCase.java AbstractTestCase.java

Posted by Emmanuel Lecharny <el...@apache.org>.
> >Ooops. May be a little convo on IRC could help a lot avoiding the code
> >breaking I induced...
> >  
> >
> Let's keep this on the list.  

+1

> Also we *MUST* always make sure we summarize our conclusions on IRC.

+1 to this kind of wish

> Please don't take this Emmanuel this is more a reminder to myself :-) as 
> well.  We neeed to watch how much info is lost on IRC now that our IRC 
> channel's are not being logged anymore.

We must find a way to log those infos, and how to publish them.


Back to the pb, what about a test-setup subproject in apacheds project?

> 
> Thanks,
> Alex
> 
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
> Aucun virus connu a ce jour par nos services n'a ete detecte.
> 
> 
> 



Re: svn commit: r307398 - in /directory/apacheds/trunk/core/src/test/org/apache/ldap/server: AbstractAdminTestCase.java AbstractNonAdminTestCase.java AbstractTestCase.java

Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:

>>The reason these are not in test is because they are base classes used 
>>by other testcases in core and in main.  These classes are used by the 
>>test code as well as by other modules.  Really the thing we have to do 
>>is break  this out as another maven project in apacheds that is 
>>specifically for apacheds-unit testing.   This way it does not get 
>>jumbled up into ApacheDS code.
>>    
>>
>
>Ooops. May be a little convo on IRC could help a lot avoiding the code
>breaking I induced...
>  
>
Let's keep this on the list.  I want others to be able to be aware as 
well and for the search engines to pick it up.  In general let's use IRC 
as a tool when there would be too much back and forth chatter.  Also we 
*MUST* always make sure we summarize our conclusions on IRC.

Please don't take this Emmanuel this is more a reminder to myself :-) as 
well.  We neeed to watch how much info is lost on IRC now that our IRC 
channel's are not being logged anymore.

Thanks,
Alex


Re: svn commit: r307398 - in /directory/apacheds/trunk/core/src/test/org/apache/ldap/server: AbstractAdminTestCase.java AbstractNonAdminTestCase.java AbstractTestCase.java

Posted by Emmanuel Lecharny <el...@gmail.com>.
> The reason these are not in test is because they are base classes used 
> by other testcases in core and in main.  These classes are used by the 
> test code as well as by other modules.  Really the thing we have to do 
> is break  this out as another maven project in apacheds that is 
> specifically for apacheds-unit testing.   This way it does not get 
> jumbled up into ApacheDS code.

Ooops. May be a little convo on IRC could help a lot avoiding the code
breaking I induced...

> 
> Alex
> 
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
> Aucun virus connu a ce jour par nos services n'a ete detecte.
> 
> 
> 


Re: svn commit: r307398 - in /directory/apacheds/trunk/core/src/test/org/apache/ldap/server: AbstractAdminTestCase.java AbstractNonAdminTestCase.java AbstractTestCase.java

Posted by Alex Karasulu <ao...@bellsouth.net>.
elecharny@apache.org wrote:

>Author: elecharny
>Date: Sun Oct  9 04:16:35 2005
>New Revision: 307398
>
>URL: http://svn.apache.org/viewcvs?rev=307398&view=rev
>Log:
>moved those three classes from the src/java directory to src/test directory
>
>Added:
>    directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractAdminTestCase.java
>    directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractNonAdminTestCase.java
>    directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractTestCase.java
>
>Added: directory/apacheds/trunk/core/src/test/org/apache/ldap/server/AbstractAdminTestCase.java
>  
>
The reason these are not in test is because they are base classes used 
by other testcases in core and in main.  These classes are used by the 
test code as well as by other modules.  Really the thing we have to do 
is break  this out as another maven project in apacheds that is 
specifically for apacheds-unit testing.   This way it does not get 
jumbled up into ApacheDS code.

Alex