[
https://issues.apache.org/jira/browse/GEODE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-319:
--------------------------------
Assignee: Ashvin (was: Anthony Baker)
> HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception
> logic is incorrect
> --------------------------------------------------------------------------------------------
>
> Key: GEODE-319
> URL: https://issues.apache.org/jira/browse/GEODE-319
> Project: Geode
> Issue Type: Bug
> Affects Versions: 1.0.0-incubating
> Reporter: Kirk Lund
> Assignee: Ashvin
>
> It's common to follow this pattern in JUnit 3.8:
> {noformat}
> try {
> //do something that will throw expected exception
> fail("Expected exception was not thrown");
> } catch (ExpectedException e) {
> //passed because ExpectedException was thrown
> }
> {noformat}
> However, the logic in testHdfsStoreInvalidCompactionConf is clearly goofed
> up. The test passes on Linux only because NO exception is being thrown but
> that should cause that this test to fail (according to javadocs). So at best
> it's a test that is not valid and should be deleted, or at worse it's hiding
> a real bug.
> {noformat}
> /**
> * Validates that cache creation fails if a compaction configuration is
> * provided which is not applicable to the selected compaction strategy
> */
> public void testHdfsStoreInvalidCompactionConf() {
> String conf = createStoreConf("123");
> try {
> this.c.loadCacheXml(new ByteArrayInputStream(conf.getBytes()));
> // expected
> } catch (CacheXmlException e) {
> fail();
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
