On Thu, 9 Aug 2001, Berin Loritsch wrote:
> 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>
I think I like this approach. Also because it will give you a place to
document your tests (you know customers will be happy if you deliver
alot of documents when you work for the their projects :)
So I'd like to add a
<annotate>
<!-- any kind of XML here but I think DocBook
fragments are preferred -->
</annotate>
> <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>
Maybe also something like this (?):
<entry name="bar" class="my.foo.BarMock">
<some config="here"/>
</entry>
It is meant to add real objects to the Context instead of Strings (maybe
for self configurable Mocks ;). I know this is not enough. Sometimes
you need to add stuff to the Context programatically and thus some
methods concerning Context handling is needed (I don't know right now if
the proposed method sets from Peter suffice, but I'm sure practice will
show what else is needed).
> <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.
Any more suggestions?
Giacomo
>
>
> 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]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
