Интеграционные тесты Grails проваливаются (на первый взгляд) случайным и неповторяющимся образом

Question

Мы пишем интеграционные тесты для нашего приложения Grails 2.0.0 с помощью плагинов Fixtures и Buid-Test-Data .

В ходе тестирования было обнаружено, что интеграционное тестирование не выполняется в определенные моменты, а проходит в другое время. Запуск «test-app» иногда приводит к прохождению всех тестов, а иногда приводит к сбою некоторых наших тестов.

Когда тесты не выполняются, они вызваны нарушением уникального ограничения во время вставки экземпляра класса домена. Это указывает на то, что в тестовой БД все еще есть записи. Я использую H2 db и определенно получил 'dbCreate = "create-drop" в моем DataSource.groovy.

Загрязнение тестов интеграции Grails 2.0? , кажется, указывает на то, что существует серьезная проблема загрязнения тестов в Grails. Есть ли какие-либо решения для этого? Я ударил Grails-8530 ?

[Редактировать] Тестовое загрязнение вызвано юнит-тестами. Мы в некотором роде доказали это, удалив модульные тесты и успешно запустив «test-app».

Answer 1

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

1) Я бы посмотрел на недавно добавленные модульные тесты.Если эта проблема только началась, то это хорошее место для поиска.

2) Метаклассификация, кажется, хороша для того, чтобы вызывать ошибки такого типа, поэтому я бы искал метаклассирование, которое не было правильно настроено / сорвано.Не столько проблема с 2.0, сколько с <= 1.3.7, но может быть проблема. </p>

3) Я написал плагин, который выполняет ваши тесты в случайном порядке.Что не может помочь вам решить вашу текущую проблему.Но что может вам помочь, так это распечатывает все ваши тесты, чтобы вы могли взять то, что он вам дал, и запустить grails test-app <pasted list of unit tests> IntegrationTestThatIsFailing, а затем начать удалять модульные тесты, чтобы найти виновника (ей).(http://grails.org/plugin/random-test-order). В этой версии 2.0 я обнаружил ошибку, которую еще не успел исправить (интеграционные тесты не выполняются при утверждении имени в визуализированном представлении), но он все равно должен распечатать для вас имена тестов (чтолучше, чем делать это самому:)

Answer 2

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

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

Во-первых, я бы попытался форсировать порядок выполнения, как упоминал Джарред в 3). Предполагая, что вы можете затем воспроизвести поведение, я бы затем проверил поведение транзакций далее. Установка уровня ведения журнала org.hibernate.transaction для отладки должна показать, где находятся границы транзакции.

Извините, пока нет хорошего объяснения, почему уничтожение модульных тестов помогает избавиться от симптомов, помимо общих "возможных проблем с метаклассированием". :)