Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <c278ac970610052021n354fc4ear6f98bbe649a8809b@mail.gmail.com>
References: <c278ac970610052021n354fc4ear6f98bbe649a8809b@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <04611A79-879F-4EAD-A7F2-490F2666450E@visi.com>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: Info needed: migrating openejb-itests to testsuite framework
Date: Fri, 6 Oct 2006 11:41:38 -0700
To: dev@geronimo.apache.org

Don't know if I have the best answers, but I'll i'll try my best...

On Oct 5, 2006, at 8:21 PM, Prasad Kashyap wrote:

> Can someone please shed some light on it
> and help me understand the present structure ?

There are actually two different structures there.

Structure One

> openejb-itests

There are some 21 beans 400 tests in this bucket.  The test suite is  
divided into four sections; stateful, stateless, cmp (1.x), bmp.  The  
tests in each section follow a pattern of starting simple and growing  
in complexity and are in logical order as much as possible.  For  
example, we test JNDI before we test that you can lookup a bean and  
use it's create method.  We try not to put the cart before the horse  
so that if something does break, you get as far though the test suite  
as possible before you encounter the breakage (rather than the very  
first test).  It's not uncommon for tests to break while refactoring.

Structure Two

> scenario1
> scenario2
> scenario3
> cmp2-prefetch
> cmp2-petstore
> cmp2-storage
> cmp2-cmrmapping

These are security and cmp2 tests.  The cmp2 tests may easily be able  
to be folded into openejb-itests, which does not have and needs a  
cmp2 section.  Dunno, haven't looked at them too much.  The security  
tests (scenario1,2,3)  use pretty much the same beans but configured  
with different plans (IIUC).  Alan and Gianny could probably fill in  
more details on those.

> Now, are these java files disjoint enough that they can be split apart
> into as many projects as the ejb archives we need ?

I think they may group together like such:

openejb-itests

scenario1
scenario2
scenario3

cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping

Don't know about the cmp2 tests, but the security tests definitely  
reuse the same classes.

> Don't think we can
> build all the classes in one core m2 project and use the classes in
> another project which has just the plan DD. Can we ?

Ejbs can use third part jars, so yes.  The bean classes and other  
classes don't actually have to be inside the same jar as the ejb- 
jar.xml and plan.  The plan for that matter doesn't have to be in the  
jar at all.

> Is the openejb-itests archive really needed ? It is the one big
> archive for the whole project that encompasses everything. It has it's
> own plan and DD and is also distributed into the server. But it also
> contains the other archives. This is kinda confusing.

The openejb-itests archive doesn't contain any other archives.  The  
module does which is probably what you meant.  As noted above, those  
other archives could likely go into their own modules.

Dunno if I really answered your question.

> I believe the test java files are in src/itest directory. However,
> they have a dependency on the java files in src/java.

IIRC, I think the ejbs themselves are in src/java and the client code  
(the unit tests) are in src/itests.

> Like I said, the
> only a subset of files in src/java are used to create archives. The
> rest are either included in that big openejb-itests archive or simply
> needed to support the junit tests in src/itests. Now why is it
> structured this way ?  Why weren't they moved to the src/itests dir
> where they are needed ?

The beans need to get packaged and deployed into the server.  The  
itests themselves could be run from maven ( no need to archive them  
really unless you want to run them again as tests in another maven  
module )

In reference to OpenEJB 3, which I guess is unlikely to be the way  
Geronimo structures it's tests, the itests are in one module as a  
plain ejb app.  We then deploy and test sever modules with them by  
declaring a dep on them with 'test' as the scope and then create  
JUnit TestSuite instances to essentially import the tests we want to  
run.  I think we run the itests about 8 times total.

[INFO] OpenEJB :: iTests .....................................  
SUCCESS [3.739s]
[INFO] OpenEJB :: Container ..................................  
SUCCESS [0.015s]
[INFO] OpenEJB :: Container :: Loader ........................  
SUCCESS [0.394s]
[INFO] OpenEJB :: Container :: Java EE .......................  
SUCCESS [2.513s]
[INFO] OpenEJB :: Container :: Core ..........................  
SUCCESS [23.354s]  (itests run 3 times)
[INFO] OpenEJB :: Container :: Persistence ...................  
SUCCESS [7.373s]
[INFO] OpenEJB :: Server .....................................  
SUCCESS [0.015s]
[INFO] OpenEJB :: Server :: Client ...........................  
SUCCESS [1.593s]
[INFO] OpenEJB :: Server :: Core .............................  
SUCCESS [2.155s]
[INFO] OpenEJB :: Server :: EJBd .............................  
SUCCESS [7.176s]  (itests run 2 times)
[INFO] OpenEJB :: Server :: Admin ............................  
SUCCESS [1.827s]
[INFO] OpenEJB :: Server :: Http .............................  
SUCCESS [8.466s]  (itests run 2 times)
[INFO] OpenEJB :: Server :: Telnet ...........................  
SUCCESS [2.324s]
[INFO] OpenEJB :: Server :: XFire ............................  
SUCCESS [1.627s]
[INFO] OpenEJB :: Server :: Axis .............................  
SUCCESS [2.207s]
[INFO] OpenEJB :: Server :: CORBA ............................  
SUCCESS [2.751s]  (not yet, but soon)
[INFO] OpenEJB :: Examples :: HelloWorld Stateful Pojo .......  
SUCCESS [3.776s]
[INFO] OpenEJB :: Examples ...................................  
SUCCESS [0.009s]

Guess that's only 7.  If you build with assemblies profile '- 
Dassemble=true' you'll get three more modules and can run the itests  
another 5 times.  In these modules we do it in maven1 still as we use  
ant/jelly to unpack our zips and stuff and run the tests against the  
final assemblies.

Not sure if that info helps what you're working on.  Let me know.

-David