[
https://issues.apache.org/jira/browse/OODT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091120#comment-14091120
]
Ross Laidlaw edited comment on OODT-741 at 8/8/14 6:48 PM:
-----------------------------------------------------------
Hi Chris,
Ah, sorry about that! I probably jumped too quickly on the commit there! I
was just itching to get a stable File Manager build :)
I'm not sure how the tests were able to pass before, because in the test class
the startUp method creates a new XMLValidationLayer object for each test:
{code}
protected void setUp() throws Exception {
...
validationLayer = new XMLValidationLayer(testDirUris);
...
}
{code}
And the data definitely persists between the tests, which would affect the
results. Perhaps the other FM unit tests used to use the same elements.xml
resource? Or maybe we were running some kind of forked/parallel tests in
different JVMs?
If we do need to make a change for the test to be more robust, do you think
that instead of removing the static modifiers from XMLValidationLayer, in the
test classes that use XMLValidationLayer we could reset it (including clearing
the elementMap) in the tearDown?
Ross
was (Author: rlaidlaw):
Hi Chris,
Ah, sorry about that! I probably jumped too quickly on the commit there! I
was just itching to get a stable File Manager build :)
I'm not sure how the tests were able to pass before, because in the test class
the startUp method creates a new XMLValidationLayer object for each test:
{code}
protected void setUp() throws Exception {
...
validationLayer = new XMLValidationLayer(testDirUris);
...
}
{code}
And the data definitely persists between the tests, which would affect the
results. Perhaps the other FM unit tests used to use the same elements.xml
resource? Or maybe we were running some kind of forked/parallel tests in
different JVMs?
If we do need to make a change for the test to be more robust, do you think
that instead of removing the static modifiers from XMLValidationLayer, in the
test class we could use a single XMLValidationObject and reset it (including
clearing the elementMap) in the tearDown?
Ross
> Should the elementMap, subToSuperMap and productTypeElementMap fields in
> XMLValidationLayer be non-static?
> ----------------------------------------------------------------------------------------------------------
>
> Key: OODT-741
> URL: https://issues.apache.org/jira/browse/OODT-741
> Project: OODT
> Issue Type: Bug
> Components: file manager
> Affects Versions: 0.7
> Reporter: Ross Laidlaw
> Assignee: Ross Laidlaw
> Labels: filemgr
> Fix For: 0.7
>
> Attachments: OODT-741.rlaidlaw.2014-08-06.patch.txt
>
>
> The TestXMLValidationLayer#testGetElements test currently fails when doing a
> full build/test of the File Manager component, with the following result:
> {panel}
> Results :
> Failed tests:
>
> testGetElements(org.apache.oodt.cas.filemgr.validation.TestXMLValidationLayer):
> There aren't exactly 4 elements in the test samples! expected:<4> but
> was:<11>
> {panel}
> This happens because the elementMap field in the XMLValidationLayer class is
> static (i.e. a class variable), so any data assigned to it persists between
> objects. When new data is written to the elementMap it is added or
> overwritten depending on the value of the String key, but data isn't removed
> from it when new XMLValidationLayer objects are created.
> The way that the test is written would imply that each XMLValidationLayer
> object should have its own elementMap. So I've experimented by removing the
> 'static' modifier from the elementMap, subToSuperMap and
> productTypeElementMap fields. This causes all TestXMLValidationLayer tests
> to pass and does not seem to affect any other File Manager tests (all other
> tests pass).
> Would this be an acceptable change or will it prevent other things from
> working?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
