Блог

Я хочу следовать TDD, но команде grails test-app CUT требуется почти минута для выполнения из-за Resolving dependencies... и Resolving new plugins. Please wait... ...

Выполнение каждого из этих двух этапов занимает около 20 секунд, в то время как тесты занимают всего несколько секунд.

(Я не уверен, влияет ли это как-либо на производительность, но я использую разрешение зависимостей через BuildConfig.groovy — и хочу придерживаться этого.)

1. Как я могу заставить grails выполнять только тесты, которые могут пропустить процесс разрешения?
2. Как еще я мог бы ускорить процесс? (Обратите внимание, что grails interactive это не может повлиять на скорость разрешения.)

У меня была похожая проблема, и я решил ее, не используя *-SNAPHOT версии каких-либо плагинов. Я понизил версию до последней версии без моментального снимка и сократил «разрешение зависимостей» с 10 секунд до 1 секунды.

Идеи:

1. Попробуйте удалить (или на всякий случай переместить) каталог /.ivy2/cache. При следующем выполнении «run-app» все зависимости будут загружены снова с нуля. После выполнения этого мое время «Разрешения зависимостей …» сократилось примерно на 5 секунд.
2. Здесь есть еще несколько советов о том, как полностью очистить ваши каталоги. Полная очистка может помочь, если у вас есть какие-то несовместимые файлы и т.д.
3. Попробуйте включить ведение журнала в BuildConfig.groovy, установив для log значение «info» в разделе grails.project.dependency.resolution. Это может дать вам лучшее представление о том, какие зависимости занимают больше всего времени.
4. Убедитесь, что ваш каталог .ivy2 находится на вашем локальном компьютере. Смотрите здесь для получения дополнительной информации

В Grails 2 появился новый вариант старой (теперь устаревшей) ‘интерактивной’ команды. Чтобы запустить его, нужно запустить grails без каких-либо аргументов (т.Е. grails <ENTER> ).

Запуск test-app оттуда, похоже, пропускает разрешение зависимостей, что в конечном итоге делает тесты теперь намного быстрее (на ~ 40 секунд меньше в упомянутом случае).

Вы должны писать свои модульные тесты таким образом, чтобы вы могли запускать их непосредственно из IDE. Мне нравится смотреть на зеленую полосу. Например, в STS / Eclipse просто выполните «Запуск от имени-> Junit Test». Если для теста требуется запуск Grails, это больше не модульный тест (это интеграционный тест).

Мне придется создать резервную копию FlareCoder для этого. Слишком многие разработчики Grails ленятся использовать модульные тесты, специфичные для Grails, или, что еще хуже, превращают все в интеграционный тест. Это нормально, если ваш проект относительно небольшой и ваша команда не возражает против запуска Grails каждый раз, но это как бы противоречит настоящему TDD.

Как только вы поймете всю мощь Groovy за пределами Grails, вам следует попробовать писать модульные тесты, не зависящие от Grails. Истинный дух модульного тестирования не требует фреймворка. У Groovy само по себе есть много способов заглушки / макета классов, которые не требуют длительного времени запуска. Тогда ваши модульные тесты могут выполняться по отдельности и в целом очень быстро. Я делаю TDD таким образом в IntelliJ IDEA на уровне метода, который выполняется очень быстро.

Неправда, что для насмешек в Grails требуется, чтобы Grails постоянно насмехался. Иногда достичь этого сложнее, чем в других случаях, но помните, Grails — это просто абстракция многих классных технологий, использующих какое-то отличное метапрограммирование, которое позволяет быстро разрабатывать. Если они работают не так, как вы ожидаете, изучите их, чтобы вы могли удалить все, что Grails делает, что вам не нужно.