Junit (3.8.1) проверяет, что генерируется исключение (работает в модульном тесте, завершается неудачей при добавлении в testSuite)

Question

Я пытаюсь проверить, что я выбрасываю исключение, когда это уместно. В моем тестовом классе у меня есть метод, подобный следующему:

public void testParseException() {

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

Это прекрасно работает (зеленая полоса) всякий раз, когда я запускаю этот единственный класс unitTest. Однако, когда я добавляю этот тест в testSuite, я получаю сообщение об ошибке модульного теста, отображаемое в исключительной ситуации, на красной полосе.

Еще одна вещь ... она работает в testSuite, если это первый тест в наборе. На самом деле, я делаю два из этих тестов и просто выяснил, что если я сделаю их первыми двумя тестами в комплекте, все будет хорошо, но я получу этот сбой, если ему предшествует «обычный» тест. Так что у меня есть обходной путь, но нет реального ответа.

Есть идеи?

Heres'a, стек трассировки "сбоя"

java.lang.RuntimeException: клиент ProcEntity dn = "Xxxxxx / Xxxx / XXX" определяется несколько раз. в com.someco.someprod.clientEntityManagement.ClientEntitySingleton.addClientEntity (ClientEntitySingleton.java:247) в com.someco.someprod.clientEntityManagement.ClientEntitySingleton.startElement (ClientEntitySingleton.java:264) at org.apache.xerces.parsers.AbstractSAXParser.startElement (неизвестный источник) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement (Неизвестный источник) at 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 (Неизвестный источник) at 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) at 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) at 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)

Answer 1

Трудно определить остальную часть кода, но есть ли другие тесты, которые используют ClientEntitySingleton и вызывают его метод getInstance? Если у вас есть синглтон с отложенной инициализацией, он не будет инициализироваться несколько раз.

Вы пытались разложить тесты на отдельную JVM и посмотреть, не возникла ли у вас проблема?

Answer 2

Просто понял, что я никогда не публиковал «ответ» на эту проблему.

ClientEntitySingleton был настроен так, чтобы при инициализации он просто кэшировал имя загружаемого XML-файла.Он загружается по первой ссылке и перезагружается, если вы измените имя файла после загрузки одноэлементных данных.

Таким образом, до тех пор, пока сбои произошли до успешной загрузки, анализ выполнялся во время теста.дело (1-й доступ).После того, как я успешно загрузил файл XML, любые будущие изменения в свойстве исходного файла вызвали немедленный анализ файла XML.К сожалению, я устанавливал имя файла в методе настройки теста.(Это на самом деле прямо в трассировке стека.)

Итак, если вы считаете, что JUnit не работает с исключениями тестирования, это не ваше подтверждение.

Answer 3

Я бы посоветовал вам не ловить RuntimeException, который имеет около тысячи подклассов.

Исходя из названия вашего класса, звучит так, как будто вы ожидаете только ParseException. Это то, что вы должны поймать в своем тесте.

Наконец, предполагая, что вы выполняете эти тесты в IDE (из-за ссылок на красные / зеленые столбцы), вы должны изучить сообщение об ошибке в данном случае - JUnit должен сообщить, какое ожидаемое сообщение было в сравнении с фактическим сообщением. является. Это поможет вам диагностировать то, что на самом деле происходит, что должно помочь вам понять, почему вы можете получить один тип поведения, когда тест выполняется изолированно, а не как группа.