On Jan 23, 2007, at 10:02 AM, Luciano Resende wrote:
Well, it looks like I might be doing more then what is required
here, but
I'll try to give some more comments on the scenario.
I assume you are trying to test an ImplementationLoader for its
handling of
duplicate components. If so, then you must simply have to focus
on that
'unit' i.e. the ImplementationLoader. You need not test if the
loader is
registered or picked up from the registry and invoked. These
things you
assume and just start with the phase when the loader is actually
invoked.
Yes, I'm trying to check for the duplicated components, and I have
added
code to handle that inside CompositeLoader.java
Through the mock reader you only need to feed those inputs that
the Loader
actually reads from the XMLReader argument. Basically you provide
mock
inputs just to the Loader and test how it handles these inputs.
So in your
case you might be feeding in duplicates to see if the loader is
able to
detect this.
So, I'm trying to mock the necessary reads just to check the
duplicate, and
the way I was thinking to do this was to provide mocked reader that
would
return two components with the same name,
but while loading the composite, compositeLoader will pass control to
various other loaders, and then will fail inside ComponentLoader with
inrecognizedElement exception trying to get a loder for the <
implementation.java... element.:
Code where it starts passing control to the registry to load other
ares of
the scdl returned by the mocked reader:
switch (reader.next()) {
case START_ELEMENT:
ModelObject o = registry.load(parent, composite,
reader,
deploymentContext);
Chain of control:
CompositeLoader
LoaderRegistryImpl
CompositeLoader
ComponentLoader
Where it fails in ComponentLoader
try {
Implementation<?> impl = loadImplementation(parent, reader,
deploymentContext);
registry.loadComponentType(parent, impl,
deploymentContext);
So, my question is more around, how can I test the CompositeLoader
without
having to go that farther in the code chain where other things are
required
?
I'll take a look at the read resources Jim sent and see if those
give me any
more ideas...
Hi Luciano,
I think the following skeleton may help - it demonstrates how to just
test the loader with the other infrastructure classes mocked out:
public class CompositeLoaderTestCase extends TestCase {
private CompositeComponent parent;
private DeploymentContext context;
private ArtifactRepository repo;
public void testFoo() throws Exception {
ComponentDefinition definition = new
ComponentDefinition<Implementation<?>>(null);
LoaderRegistry registry = EasyMock.createMock
(LoaderRegistry.class);
EasyMock.expect(registry.load(EasyMock.isA
(CompositeComponent.class),
EasyMock.isA(ModelObject.class),
EasyMock.isA(XMLStreamReader.class),
EasyMock.isA(DeploymentContext.class))).andReturn
(definition);
EasyMock.replay(registry);
XMLStreamReader reader = EasyMock.createMock
(XMLStreamReader.class);
EasyMock.expect(reader.getAttributeValue(null,
"name")).andReturn("foo");
EasyMock.expect(reader.next()).andReturn
(XMLStreamConstants.START_ELEMENT);
EasyMock.expect(reader.next()).andReturn
(XMLStreamConstants.END_ELEMENT);
EasyMock.expect(reader.next()).andReturn
(XMLStreamConstants.END_ELEMENT);
EasyMock.expect(reader.getName()).andReturn
(CompositeLoader.COMPOSITE);
EasyMock.replay(reader);
CompositeLoader loader = new CompositeLoader(registry, repo);
CompositeComponentType<ServiceDefinition,
ReferenceDefinition, Property<?>> type =
loader.load(parent, null, reader, context);
EasyMock.verify(registry);
EasyMock.verify(reader);
}
protected void setUp() throws Exception {
super.setUp();
parent = EasyMock.createMock(CompositeComponent.class);
EasyMock.replay(parent);
context = EasyMock.createMock(DeploymentContext.class);
EasyMock.replay(context);
repo = EasyMock.createMock(ArtifactRepository.class);
EasyMock.replay(repo);
}
}
HTH
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
