avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: JUnit AvalonTestCase
Date Thu, 09 Aug 2001 07:20:00 GMT
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.


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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org



| "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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message