Mvn test не проходит, но тесты проходят, если запускаются для каждого пакета

У меня есть проект со следующей структурой

src
  |_ main
  |   |_ java
  |       |_ com.company.product
  |           |_ packageA
  |           |_ packageB
  |_ test
      |_ java
          |_ com.company.product
              |_ packageA
              |_ packageB

При запуске mvn test мои тесты в packageA проходят, а тесты в packageB терпят неудачу. При запуске mvn test -Dtest = "com.company.product.packageB.**" тесты в packageB проходят. Более того, при запуске mvn test -Dtest = "com.company.product.**" также не проходят тесты packageB, но не тесты packageA. Почему mvn test не проходит все тесты, которые должны пройти?

Подробная информация о тестах в packageB:

@Test
void createNew() {
    String user = "testUser";

    //This calls a third party API that is throwing a 
    //InvocationTargetException when running packages together
    Connection connect = new Connection(user);
    String resultText = connect.getResultText();

    assertNotNUll(connect);
    assert (resultText).equals("Process Complete");
}

Баночка, необходимая для запуска стороннего вызова API, включена в pom следующим образом.

    <dependency>
        <groupId>com.third.party.api</groupId>
        <artifactId>third-party-api</artifactId>
        <version>1.0.0</version>
    </dependency>

Использование Java 1.8.0_74 и Maven 3.5.4.

Обновлено: Ошибка, возвращенная Maven:

createNew()  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
        at com.company.product.packageB.MyTest.createNew(MyTest.java:11)
Caused by: java.lang.reflect.InvocationTargetException
        at com.company.product.packageB.MyTest.createNew(MyTest.java:11)
Caused by: java.lang.RuntimeException: Error when creating RpcClientStub. Cause : java.lang.NoClassDefFoundError: Could not i
nitialize class com.third.party.apitransport.session.ArRpcCallContext
        at com.company.product.packageB.MyTest.createNew(MyTest.java:11)

...

Results :

Tests in error:
  MyTest.createNew:11 » Runtime java.lang.reflect.InvocationTargetEx...
  MyTest.createAndUpdate:29 » Runtime java.lang.reflect.Invocation...
  MyTest.connect:51 » Runtime java.lang.reflect.InvocationTarget...

Tests run: 9, Failures: 0, Errors: 3, Skipped: 0

Обновлено: Исправление заключалось в добавлении очистки, как указал Иван в комментариях.

private static String systemOsName;
@BeforeAll
public static void setOsName(){
    systemOsName = System.getProperty("os.name");
}
...
@AfterAll
public static void cleanup(){
    Constants.setFilePathSeparator("");
    System.setProperty("os.name",systemOsName);
}

Вы должны опубликовать полную ошибку, возвращаемую Maven.

Martín Straus 27.09.2018 17:51

Предположительно они борются за какой-то общий ресурс.

Oliver Charlesworth 27.09.2018 17:55

У меня есть 3 теста в MyTest.java, и все 3 теста проходят вместе. Вы имеете в виду, что пакеты конкурируют за общий ресурс? PackageA не использует сторонний api, который находится в строке, вызывающей ошибку, для справки.

John B. 27.09.2018 17:58

Похоже, что тесты в packageA не выполняют очистку (закрытие ресурсов / соединений, удаление созданных файлов, откат изменений в базе данных) после их завершения. Из-за этого тесты в packageB не могут инициализировать эти ресурсы.

Ivan 27.09.2018 18:29

Не уверен, какие ресурсы нужно очистить. Тесты packageA очень простые. Следующее примерно так же сложно, как и получается: gist.github.com/JohnSBarden/1475872f2feb4133c7d1e9d544e4f1f8

John B. 27.09.2018 18:38
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
1
5
135
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Если есть несколько тестов, которые устанавливают значение System.setProperty("os.name", "windows"), то его нужно будет сбросить в конце с очисткой, если это значение будет использоваться для определения значения позже в ваших тестах пакета b.

Другие вопросы по теме