Тесты Maven Spring не выполняются при совместном запуске, но выполняются индивидуально (ehcache закрыто, IllegalTransactionStateException) - PullRequest
6 голосов
/ 21 апреля 2010

Мы используем транзакционные тесты Maven / Surefire и Spring / Hibernate для довольно большого веб-приложения. Всего существует 138 тестовых * классов, в общей сложности 1178 тестов.

Простое mvn test сгенерирует 82 ошибки, природа которых подразумевает поврежденный контекст приложения:

Многие из них:

IllegalTransactionStateException: Pre-bound JDBC Connection found!

Некоторые из них:

NoSuchMethodError: org.hibernate.cache.CacheException.<init>(Ljava/lang/Exception;)V

Для каждого неудачного теста индивидуальный запуск класса теста mvn test -Dtest=TestFailingClass завершается успешно. В самом деле, использование - Dtest=TestClass1,TestClass2,Etc с различными подмножествами всех моих тестовых классов успешно или неудачно по-разному. Например, выполнение только тестовых классов с ошибками завершается успешно с 0 ошибками.

Не имея очевидных средств для контроля порядка классов, тестируемых Surefire, мне трудно определить, какой из моих тестовых классов, похоже, оставляет контекст в плохом состоянии.

То, что я ищу, - это стратегия, помогающая определить, что происходит каким-то детерминированным образом. Я, конечно, могу видеть порядок выполнения тестов из журнала, но я не могу воспроизвести этот порядок контролируемым образом.

И, конечно, предложения, что с этим делать ...

Ответы [ 3 ]

2 голосов
/ 27 апреля 2010

Действительно, проблема связана с поврежденным контекстом приложения Spring.Одним из ранних тестов является загрязнение контекста и ошибка следующих тестов.

Одной из сложностей является попытка контролировать порядок тестов при обнаружении теста, вызывающего проблему.

Iсмог достичь этого, используя журнал Maven для определения порядка выполнения тестовых классов, а затем исключая тесты по одному сверху.Тридцать четыре теста, я нашел виновника.

Это был тест под названием TestSpringContexts.Добавление @DirtiesContext к этим тестам решает проблему, но она также решается удалением вызовов context.close () из тестов.

Я написал сообщение в блоге об этом процессе, но это сутьдело: http://mojo.whiteoaks.com/2010/04/27/finding-the-test-that-corrupts-the-suite/

Моджо

1 голос
/ 22 апреля 2010

Не имея очевидных средств для контроля порядка классов, тестируемых Surefire, мне трудно определить, какой из моих тестовых классов, похоже, оставляет контекст в плохом состоянии.

Действительно. А выполнение подмножеств тестов даст разные результаты (с точки зрения порядка выполнения), что затруднит отладку вашей проблемы.

Но вы можете использовать патч из SUREFIRE-321 ( Выполнить тесты в алфавитном порядке ), чтобы получить лучший контроль (проверьте комментарии, один из плакатов был очень проблема похожая на вашу).

0 голосов
/ 25 июня 2018

Добавьте @Dirtiescontext(classMode = classmode.AFTER_CLASS) в каждом тестовом случае.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...