[ https://issues.apache.org/jira/browse/GEODE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kirk Lund reassigned GEODE-319: ------------------------------- Assignee: Anthony Baker Code Review reveals problem in logic of test. Not sure who to assign this to. > 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: Anthony Baker > > 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)