Как эффективно выполнить модульное тестирование при использовании разрешения зависимостей через BuildConfig.groovy в Grails? - PullRequest
1 голос
/ 08 мая 2011

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

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

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

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

Ответы [ 5 ]

2 голосов
/ 15 сентября 2011

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

2 голосов
/ 08 июня 2011

Идеи:

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

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

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

0 голосов
/ 12 декабря 2011

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

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

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

0 голосов
/ 15 сентября 2011

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

...