You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Marcus Crafter <cr...@managesoft.com> on 2004/10/05 20:17:14 UTC

Testing/debugging components?

Hi All,

Hope all is going well.

I was wondering if there was any interest out there for building some
junit and Eclipse plugin's for enhancing support for testing/debugging
components, etc?

Currently, I find it a little difficult to write a junit test case for a
component because it requires a container, or at least something to
bring it through it's startup/shutdown lifecycle.

So I thought about building something that would let you create a
"component test case" that would let you associate a configuration, etc,
amongst other things with a component. This would make it a bit easier
to initialize the component in question, and then the test* methods
could then operate on it.

I'm sure there's many other things we could do to make it easier to work
with components and fortress in general inside of eclipse - any ideas?

What does everyone think?

Cheers,

Marcus

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Leif,

Cool, thanks for the information mate - will take a look at it over the
weekend then! :)

Cheers,

Marcus

On Fri, 2004-10-08 at 07:06, Leif Mortenson wrote:
> I had a similar need for testing Fortress components a couple weeks ago 
> and added a new
> very simple project under fortress.  It is simple, and undocumented.  
> But it works.
> Checkout the code fro SVN, and look at /fortress/testcase/
> An example test case is included in the src/test directory.
> 
> Cheers,
> Leif
> 
> Peter Donald wrote:
> 
> > Leo Simons wrote:
> >
> >>> I guess I'm not really looking to do too much, perhaps create an
> >>> abstract test case class that has an associated xconf fragment, that
> >>> defines how the component should be instantiated/created by the
> >>> container, and the rest would be normal junit processing.
> >>
> >>
> >>
> >> don't we have something like that already? I'm sure I saw it 
> >> somewhere sometime...
> >
> >
> > The "testcase" component did something similar for ECM.
> >
> >>> I think most of us have custom solutions in our workareas to do this
> >>> already
> >>
> >>
> >>
> >> prolly. Another thing I seem to recall is Pete has some of this 
> >> hammered out for DNA (jcontainer.org).
> >
> >
> >
> > The testing part never got finished and released.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> > For additional commands, e-mail: dev-help@excalibur.apache.org
> > Apache Excalibur Project -- URL: http://excalibur.apache.org/
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
> Apache Excalibur Project -- URL: http://excalibur.apache.org/
-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft Corporation
     $       o_)$$$:   Frankfurt am Main, Germany
     ;$,    _/\ &&:'
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Leif Mortenson <le...@tanukisoftware.com>.
I had a similar need for testing Fortress components a couple weeks ago 
and added a new
very simple project under fortress.  It is simple, and undocumented.  
But it works.
Checkout the code fro SVN, and look at /fortress/testcase/
An example test case is included in the src/test directory.

Cheers,
Leif

Peter Donald wrote:

> Leo Simons wrote:
>
>>> I guess I'm not really looking to do too much, perhaps create an
>>> abstract test case class that has an associated xconf fragment, that
>>> defines how the component should be instantiated/created by the
>>> container, and the rest would be normal junit processing.
>>
>>
>>
>> don't we have something like that already? I'm sure I saw it 
>> somewhere sometime...
>
>
> The "testcase" component did something similar for ECM.
>
>>> I think most of us have custom solutions in our workareas to do this
>>> already
>>
>>
>>
>> prolly. Another thing I seem to recall is Pete has some of this 
>> hammered out for DNA (jcontainer.org).
>
>
>
> The testing part never got finished and released.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
> Apache Excalibur Project -- URL: http://excalibur.apache.org/
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Peter Donald <pe...@realityforge.org>.
Leo Simons wrote:

>> I guess I'm not really looking to do too much, perhaps create an
>> abstract test case class that has an associated xconf fragment, that
>> defines how the component should be instantiated/created by the
>> container, and the rest would be normal junit processing.
>
>
> don't we have something like that already? I'm sure I saw it somewhere 
> sometime...

The "testcase" component did something similar for ECM.

>> I think most of us have custom solutions in our workareas to do this
>> already
>
>
> prolly. Another thing I seem to recall is Pete has some of this 
> hammered out for DNA (jcontainer.org).


The testing part never got finished and released.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Peter,

On Sat, 2004-10-09 at 23:52, peter royal wrote:
> > Essentially I'd like to be able to say - show me all the places where
> > this component has been "looked up" in client code so you can see where
> > it's been used - I guess in reality its just an enhanced (or limited,
> > depending on perspective :) ) search.
> 
> Will a 'Find Usages' on the interface not work? Thats what I do in IDEA.

Yep - that does the trick, at least by doing a 'References->Project' on
the interface name.

Thanks for the tip.

Cheers,

Marcus


-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft Corporation
     $       o_)$$$:   Frankfurt am Main, Germany
     ;$,    _/\ &&:'
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by peter royal <pr...@apache.org>.
On Oct 8, 2004, at 8:50 AM, Marcus Crafter wrote:
> In Avalon though, the container runs the constructor and lifecycle of
> the component, so opening the call hierarchy of any lifecycle method
> always points you to the container utils code, and the call hierarchy 
> of
> the constructor always points to no-where (cos' its all done via
> reflection).
>
> Essentially I'd like to be able to say - show me all the places where
> this component has been "looked up" in client code so you can see where
> it's been used - I guess in reality its just an enhanced (or limited,
> depending on perspective :) ) search.

Will a 'Find Usages' on the interface not work? Thats what I do in IDEA.
-pete


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Leo,

On Fri, 2004-10-08 at 01:07, Leo Simons wrote:
> Marcus Crafter wrote:
> > BTW - will we be seeing you at this years GetTogether in Gent?
> 
> hehehe: http://jroller.com/trackback/lsd/Weblog/lsd_gettogether_nope

I see... well, perhaps next time then :)

> > I guess I'm not really looking to do too much, perhaps create an
> > abstract test case class that has an associated xconf fragment, that
> > defines how the component should be instantiated/created by the
> > container, and the rest would be normal junit processing.
> 
> don't we have something like that already? I'm sure I saw it somewhere 
> sometime...

I'm not sure, but the references Peter and Lief look promising - will go
chase up their responses (thanks guys!)

> > * The JUnit style help described above
> > 
> > * Something like 'Open Call Hierarchy', but slightly different in that
> > it displays references where the given component was 'looked up'.
> 
> no idea what that is...

When you invoke 'Open Call Hierarchy' on a method/constructor, Eclipse
will present you with the places where that method/constructor was
called - so you can easily see where it has been invoked which I find
useful.

In Avalon though, the container runs the constructor and lifecycle of
the component, so opening the call hierarchy of any lifecycle method
always points you to the container utils code, and the call hierarchy of
the constructor always points to no-where (cos' its all done via
reflection).

Essentially I'd like to be able to say - show me all the places where
this component has been "looked up" in client code so you can see where
it's been used - I guess in reality its just an enhanced (or limited,
depending on perspective :) ) search.

> > * Something that extends the compiler to generate the
> > metadata/services.list, etc, so that running/debugging in eclipse works
> > out of the box.
> 
> couldn't we just write a no-external-files-needed version of fortress so 
> that running/debugging works out of any box? Must be possible.

Sure, must be possible. We'd still need to generate the meta-data and
put it into the Eclipse environment, but replacing the xconf would be
too difficult I guess (?)

> > I'm sure there are others?
> 
> I dunno; not so big on UI stuff. Eclipse/GTK seems real slow (on linux 
> that is). I doubt I want to use it :-D

Must need a faster machine then :)

Cheers mate.

Marcus

PS. Torsten and I just thought of another one, the ability to
graphically view the dependency tree of components that look each other
up.

> -LSD
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
> Apache Excalibur Project -- URL: http://excalibur.apache.org/
-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft Corporation
     $       o_)$$$:   Frankfurt am Main, Germany
     ;$,    _/\ &&:'
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Leo Simons <ls...@jicarilla.org>.
Marcus Crafter wrote:
> BTW - will we be seeing you at this years GetTogether in Gent?

hehehe: http://jroller.com/trackback/lsd/Weblog/lsd_gettogether_nope

> I guess I'm not really looking to do too much, perhaps create an
> abstract test case class that has an associated xconf fragment, that
> defines how the component should be instantiated/created by the
> container, and the rest would be normal junit processing.

don't we have something like that already? I'm sure I saw it somewhere 
sometime...

> I think most of us have custom solutions in our workareas to do this
> already

prolly. Another thing I seem to recall is Pete has some of this hammered 
out for DNA (jcontainer.org).

> Cool, well I think I better have something written up first :)

hehehe. You were an avalon committer and you worked on this before, so I 
consider you "emeritus". Dunno what others think :-D

> I was thinking of some of the following:
> 
> * Wizards for creating component interfaces and implementations
> (including auto generation of the @qdox tags for metadata).

IDEA has "templates" and "live templates". I had a whole bunch of those 
set up at some point for stuff like this. Must be around somewhere...I 
could go hunt the archives if someone is interested...

> * The JUnit style help described above
> 
> * Something like 'Open Call Hierarchy', but slightly different in that
> it displays references where the given component was 'looked up'.

no idea what that is...

> * Something that extends the compiler to generate the
> metadata/services.list, etc, so that running/debugging in eclipse works
> out of the box.

couldn't we just write a no-external-files-needed version of fortress so 
that running/debugging works out of any box? Must be possible.

> I'm sure there are others?

I dunno; not so big on UI stuff. Eclipse/GTK seems real slow (on linux 
that is). I doubt I want to use it :-D

-LSD


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Marcus Crafter <cr...@managesoft.com>.
On Tue, 2004-10-05 at 21:14, Leo Simons wrote:
> Marcus Crafter wrote:
> > Hi All,
> 
> Hi Marcus! Good to hear from ya :-D

Hi Leo,

Likewise mate. Thanks for your reply.

BTW - will we be seeing you at this years GetTogether in Gent?

> > Hope all is going well.
> > 
> > I was wondering if there was any interest out there for building some
> > junit and Eclipse plugin's for enhancing support for testing/debugging
> > components, etc?
> 
> you might want to look at MerlinDeveloper (or whatever they're calling 
> it now), some eclipse plugins mainly by Andreas Oberhack to do just that 
> in a merlin env. (LSD ducks...)

Ok, thanks for the tip - I'll take a look at it and see what they've
done.

> > Currently, I find it a little difficult to write a junit test case for a
> > component because it requires a container, or at least something to
> > bring it through it's startup/shutdown lifecycle.
> 
> I'm not a big fan of custom *unit* test frameworks; its very important 
> to test in isolation, and when you test inside a container that's no 
> longer isolation. But that's just me :-D

Sure.

I guess I'm not really looking to do too much, perhaps create an
abstract test case class that has an associated xconf fragment, that
defines how the component should be instantiated/created by the
container, and the rest would be normal junit processing.

I think most of us have custom solutions in our workareas to do this
already (either this or we manually bring the component through it's
lifecycle in the test case) - I was hoping we could put all those ideas
into something "standard" perhaps.

An Eclipse extension would then let you drive the same test through the
JUnit plugin. That was the hope anyway! :)

> > So I thought about building something that would let you create a
> > "component test case" that would let you associate a configuration, etc,
> > amongst other things with a component. This would make it a bit easier
> > to initialize the component in question, and then the test* methods
> > could then operate on it.
> 
> A few versions of such a thing have been built over the years. The first 
> one used to be called PUnit and was a "phoenix emulator". I dunno 
> whether that lives on at loom; prolly...

Ok. Cool, will take a look at that as well then, thanks.

> > I'm sure there's many other things we could do to make it easier to work
> > with components and fortress in general inside of eclipse - any ideas?
> 
> I'm just now learning a little eclipse (I use IDEA as my IDE). There's 
> no doubt interest in this from other users. If you want to get to work 
> on it over here just holler and we can get you hooked up to SVN (after a 
> vote of course ;).

Cool, well I think I better have something written up first :)

I was thinking of some of the following:

* Wizards for creating component interfaces and implementations
(including auto generation of the @qdox tags for metadata).

* The JUnit style help described above

* Something like 'Open Call Hierarchy', but slightly different in that
it displays references where the given component was 'looked up'.

* Something that extends the compiler to generate the
metadata/services.list, etc, so that running/debugging in eclipse works
out of the box.

* and a few others I'm trying to remember :)

I'm sure there are others? 

Cheers,

Marcus


-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft Corporation
     $       o_)$$$:   Frankfurt am Main, Germany
     ;$,    _/\ &&:'
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Re: Testing/debugging components?

Posted by Leo Simons <ls...@jicarilla.org>.
Marcus Crafter wrote:
> Hi All,

Hi Marcus! Good to hear from ya :-D

> Hope all is going well.
> 
> I was wondering if there was any interest out there for building some
> junit and Eclipse plugin's for enhancing support for testing/debugging
> components, etc?

you might want to look at MerlinDeveloper (or whatever they're calling 
it now), some eclipse plugins mainly by Andreas Oberhack to do just that 
in a merlin env. (LSD ducks...)

> Currently, I find it a little difficult to write a junit test case for a
> component because it requires a container, or at least something to
> bring it through it's startup/shutdown lifecycle.

I'm not a big fan of custom *unit* test frameworks; its very important 
to test in isolation, and when you test inside a container that's no 
longer isolation. But that's just me :-D

> So I thought about building something that would let you create a
> "component test case" that would let you associate a configuration, etc,
> amongst other things with a component. This would make it a bit easier
> to initialize the component in question, and then the test* methods
> could then operate on it.

A few versions of such a thing have been built over the years. The first 
one used to be called PUnit and was a "phoenix emulator". I dunno 
whether that lives on at loom; prolly...

> I'm sure there's many other things we could do to make it easier to work
> with components and fortress in general inside of eclipse - any ideas?

I'm just now learning a little eclipse (I use IDEA as my IDE). There's 
no doubt interest in this from other users. If you want to get to work 
on it over here just holler and we can get you hooked up to SVN (after a 
vote of course ;).


cheers,


- Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/