I will echo Peter on this: +1, Excellent!
I would like to see the test cases configurable.
Something along these lines would be incredible:
<testcase>
<logger>
<!-- will follow the standards for Excalibur Logger Configurator
when it is built. the "logger" element will be passed to it -->
</logger>
<context>
<entry name="foo" value="bar"/>
</context>
<roles>
<!-- follows the standards for Excalibur Role Manager
in fact the "roles" element is passed to it -->
</roles>
<components>
<!-- follows the standards for Excalibur Component Manager
in fact the "components" element is passed to it -->
</components>
</testcase>
Any aditional test parameters can be placed inside the "testcase" element
or an agreed upon subelement.
This way, we can use the same test cases to excersize a number of different
components--with realistic interactions.
Peter Donald wrote:
>
> On Thu, 9 Aug 2001 15:31, giacomo wrote:
> > The idea came when I was looking at the DataSourceTestCase (and wanted
> > to adapt it for my own components). When one needs to test Components
> > you'll mostly need to create a logger (Loggable), maybe a Context
> > (Contextualizable), a Configuration object (Configurable) and sometimes
> > also a ComponentManager (Composer). And at least here where you have to
> > test a Composer you probably wish to have a CM setup easily. This is
> > what the aforementioned TestCases should set up for you.
> >
> > If there is interest I'd like to contribute specialized JUnit
> > TestCases for Avalon. I initially thought of two TestCases:
> >
> > FrameworkTestCase (uses framework.component.DefaultComponentManager)
> > ExcaliburTestCase (uses excalibur.component.ExcaliburComponentManager)
>
> woohoo - excelent ;)
>
> > The discussion I'd like to make is about how things like Context,
> > Configuration (be it an already created Configuration object, a String
> > or a File containing the configuration) and the roles got passed into
> > the TestCase for setup of the CM. The possibilities are:
> >
> > Constructor:
> > This would set it up once for every test in the class but
> > gives no possibility to change it (ie. Configuration,
> > Context) for different tests.
> >
> > separate method:
> > This would allow to use it as a test case itself and it
> > could be called every time you need to change something.
>
> +1
>
> You could have a set of utility methods that create CM/Context/Conf via
> whatever methods necessary. Then have another method setupComponent() that
> sets up each component as required. So it would look something like
>
> Context createContext( Component component ) { ... }
>
> Context getContext( Component component )
> {
> if( null == m_context ) m_context = createContext( component );
> return m_context;
> }
>
> void setupComponent( Component component )
> {
> ...
> if( component instanceof Context )
> {
> final Context context = getContext( component );
> component.contextualize( context );
> }
> ...
> }
>
> That way you could overide any particular stage you needed to (ie if you
> needed to use ExcaliburCM then overide createCM(), if you need per component
> context then overide getContext() to always return createContext() etc.
>
> So what do you think ?
>
> I am not sure how feasible that is but thats the way I do most of my stuff ;)
>
> > setup/tearDown method:
> > This would set up the CM for every test (including disposing
> > of the component itself in the tearDown method) but also no
> > way to use different configs for different tests in the same
> > TestCase.
> >
> > Thoughts?
> >
> > Giacomo
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
