Junit (3.8.1) 测试是否抛出异常(在单元测试中有效,添加到 testSuite 时失败)

发布于 2024-08-20 23:30:31 字数 3167 浏览 5 评论 0原文

我正在尝试测试我是否在适当的时候抛出异常。在我的测试类中,我有一个类似于以下内容的方法:

public void testParseException() {

    try {
        ClientEntitySingleton.getInstance();
        fail("should have thrown exception.");
    } catch (RuntimeException re) {
        assertEquals(
            "<exception message>",
            re.getMessage());
    }
}

每当我运行该单个 unitTest 类时,该方法都可以正常工作(绿色条)。但是,当我将该测试添加到 testSuite 时,我收到了关于异常的红色条单元测试失败报告。

还有一件事......它在 testSuite 中工作,如果它是套件中的第一个测试。实际上,我正在做其中两个测试,并且刚刚发现,如果我将它们作为套件中的前两个测试,一切都很好,但是如果在其之前进行“常规”测试,我会遇到此失败。所以我有一个解决方法,但没有真正的答案。

有什么想法吗?

这是“失败”

java.lang.RuntimeException 的堆栈跟踪:ProcEntity client dn="Xxxxxx/Xxxx/XXX" 被定义了多次。 在 com.someco.someprod.clientEntityManagement.ClientEntitySingleton.addClientEntity(ClientEntitySingleton.java:247) 在 com.someco.someprod.clientEntityManagement.ClientEntitySingleton.startElement(ClientEntitySingleton.java:264) 在 org.apache.xerces.parsers.AbstractSAXParser.startElement(来源未知) 在 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(来源未知) 在 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(来源未知) 在 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(来源未知) 在 org.apache.xerces.parsers.XML11Configuration.parse(来源未知) 在 org.apache.xerces.parsers.XML11Configuration.parse(来源未知) 在 org.apache.xerces.parsers.XMLParser.parse(来源未知) 在 org.apache.xerces.parsers.AbstractSAXParser.parse(来源未知) 在 com.someco.someprod.clientEntityManagement.ClientEntitySingleton.parse(ClientEntitySingleton.java:216) 在 com.someco.someprod.clientEntityManagement.ClientEntitySingleton.reload(ClientEntitySingleton.java:303) 在 com.someco.someprod.clientEntityManagement.ClientEntitySingleton.setInputSourceProvider(ClientEntitySingleton.java:88) 在 com.someco.someprod.clientEntityManagement.test.TestClientBase.setUp(TestClientBase.java:17) 在 com.someco.someprod.clientEntityManagement.test.TestClientEntityDup.setUp(TestClientEntityDup.java:8) 在 junit.framework.TestCase.runBare(TestCase.java:125) 在 junit.framework.TestResult$1.protect(TestResult.java:106) 在 junit.framework.TestResult.runProtected(TestResult.java:124) 在 junit.framework.TestResult.run(TestResult.java:109) 在 junit.framework.TestCase.run(TestCase.java:118) 在 junit.framework.TestSuite.runTest(TestSuite.java:208) 在 junit.framework.TestSuite.run(TestSuite.java:203) 在 junit.framework.TestSuite.runTest(TestSuite.java:208) 在 junit.framework.TestSuite.run(TestSuite.java:203) 在org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) 在 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) 在 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) 在 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) 在 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) 在 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

I'm trying to test that I'm throwing an exception when appropriate. In my test class I have a method similar to the following:

public void testParseException() {

    try {
        ClientEntitySingleton.getInstance();
        fail("should have thrown exception.");
    } catch (RuntimeException re) {
        assertEquals(
            "<exception message>",
            re.getMessage());
    }
}

This works fine (green bar) whenever I run that single unitTest class. However, when I add that test to a testSuite, I get a red bar Unit test failure reported on the exception.

One more thing... it works in the testSuite, if it's the first test in the suite. Actually, I'm doing two of these tests and just figured out that if I make them the first two tests in the suite, all is good, but I get this failure if a "regular" test precedes it. So I have a work-around, but no real answer.

Any ideas?

Heres'a stack trace of the "failure"

java.lang.RuntimeException: ProcEntity client dn="Xxxxxx/Xxxx/XXX" is defined multiple times.
at com.someco.someprod.clientEntityManagement.ClientEntitySingleton.addClientEntity(ClientEntitySingleton.java:247)
at com.someco.someprod.clientEntityManagement.ClientEntitySingleton.startElement(ClientEntitySingleton.java:264)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.someco.someprod.clientEntityManagement.ClientEntitySingleton.parse(ClientEntitySingleton.java:216)
at com.someco.someprod.clientEntityManagement.ClientEntitySingleton.reload(ClientEntitySingleton.java:303)
at com.someco.someprod.clientEntityManagement.ClientEntitySingleton.setInputSourceProvider(ClientEntitySingleton.java:88)
at com.someco.someprod.clientEntityManagement.test.TestClientBase.setUp(TestClientBase.java:17)
at com.someco.someprod.clientEntityManagement.test.TestClientEntityDup.setUp(TestClientEntityDup.java:8)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

南风几经秋 2024-08-27 23:30:31

如果没有看到其余代码,很难判断,但是是否有其他测试正在使用 ClientEntitySingleton 并调用其 getInstance 方法?如果您有一个惰性初始化单例,那么它不会被多次初始化。

您是否尝试将测试分叉到单独的 JVM 中,看看问题是否仍然存在?

Without seeing the rest of the code it's difficult to tell, but are there other tests that are using ClientEntitySingleton and calling its getInstance method? If you have a lazy init singleton, then it wouldn't be being initialized multiple times.

Have you tried forking the tests into a separate JVM and see if you still have the problem?

烟─花易冷 2024-08-27 23:30:31

我建议您不要捕获 RuntimeException,它有大约一千个子类。

根据您的类的名称,听起来好像您只期待 ParseException。这是你应该在测试中捕捉到的。

最后,假设您正在 IDE 中运行这些测试(因为引用了红色/绿色条),您应该检查案例的失败消息 - JUnit 应该报告预期消息与实际消息。这将帮助您诊断实际发生的情况,这应该可以帮助您弄清楚为什么在单独运行测试与作为一组运行测试时可能会出现一种类型的行为。

I would suggest that you do not catch RuntimeException, which has about a thousand subclasses.

Based on the name of your class, it sounds as if you are only expecting ParseException. This is what you should be catching in your test.

Finally, assuming that you are running these tests in an IDE (because of the references to red/green bars), you should examine the failure message of the case - JUnit should report what the expected message was versus what the actual message is. This will help you diagnose what is actually going on, which should help you figure out why you might get one type of behavior when the test is run isolated vs run as a group.

天生の放荡 2024-08-27 23:30:31

刚刚意识到我从未发布过这个问题的“答案”。

ClientEntitySingleton 的设置是为了在初始化时,它会简单地缓存要加载的 xml 文件的名称。它在第一次引用时加载,如果加载单例数据后更改文件名,则会重新加载。

因此,只要在成功加载之前发生故障,解析就会在测试用例(第一次访问)期间发生。一旦我成功加载了 XML 文件,以后对源文件属性的任何更改都会触发对 XML 文件的立即解析。不幸的是,我在测试设置方法中设置了文件名。 (这实际上就在堆栈跟踪中。)

因此,如果您认为 JUnit 无法处理测试异常,那么这并不是您的确认。

Just realized that I never posted the "answer" to this problem.

The ClientEntitySingleton was set up so that on initialization, it would simply cache the name of the xml file to be loaded. It is loaded on first reference, and it is reloaded if you change the file name once the singleton data is loaded.

So, as long as the failures occurred before a successful load, the parse took place during the test case (1st access). Once I had successfully loaded an XML file, any future changes to the source file property triggered an immediate parse of the XML file. Unfortunately, I was setting the file name in the test setup method. (That's actually right there in the stack trace.)

So, if you think JUnit is not working with testing exceptions, this isn't your confirmation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文