[jira] [Updated] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect
[
https://issues.apache.org/jira/browse/GEODE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-319:
Assignee: (was: Ashvin)
Component/s: hdfs
> HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception
> logic is incorrect
>
>
> Key: GEODE-319
> URL: https://issues.apache.org/jira/browse/GEODE-319
> Project: Geode
> Issue Type: Sub-task
> Components: hdfs
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>
> 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)
[jira] [Updated] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect
[
https://issues.apache.org/jira/browse/GEODE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-319:
Issue Type: Sub-task (was: Bug)
Parent: GEODE-10
> HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception
> logic is incorrect
>
>
> Key: GEODE-319
> URL: https://issues.apache.org/jira/browse/GEODE-319
> Project: Geode
> Issue Type: Sub-task
>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)
[jira] [Updated] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect
[
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)
[jira] [Updated] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect
[
https://issues.apache.org/jira/browse/GEODE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-319:
Description:
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 (). 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}
public void testHdfsStoreInvalidCompactionConf() {
assumeThat(SystemUtils.isWindows(), is(false));
String conf = createStoreConf("123");
try {
this.c.loadCacheXml(new ByteArrayInputStream(conf.getBytes()));
// expected
} catch (CacheXmlException e) {
fail();
}
}
{noformat}
was:
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. The
test passes Linux only because NO exception is being thrown but would mean that
this test should fail (if there really is an expected exception). 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}
public void testHdfsStoreInvalidCompactionConf() {
assumeThat(SystemUtils.isWindows(), is(false));
String conf = createStoreConf("123");
try {
this.c.loadCacheXml(new ByteArrayInputStream(conf.getBytes()));
// expected
} catch (CacheXmlException e) {
fail();
}
}
{noformat}
> 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
>
> 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 (). 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}
> public void testHdfsStoreInvalidCompactionConf() {
> assumeThat(SystemUtils.isWindows(), is(false));
> 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)
[jira] [Updated] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect
[
https://issues.apache.org/jira/browse/GEODE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-319:
Description:
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}
was:
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}
> 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
>
> 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)
[jira] [Updated] (GEODE-319) HDFSConfigJUnitTest testHdfsStoreInvalidCompactionConf expected exception logic is incorrect
[
https://issues.apache.org/jira/browse/GEODE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-319:
Description:
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}
was:
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 (). 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}
public void testHdfsStoreInvalidCompactionConf() {
assumeThat(SystemUtils.isWindows(), is(false));
String conf = createStoreConf("123");
try {
this.c.loadCacheXml(new ByteArrayInputStream(conf.getBytes()));
// expected
} catch (CacheXmlException e) {
fail();
}
}
{noformat}
> 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
>
> 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)
