Статьи

Grails 1.1 и Maven, взятые для тест-драйва

Декабрь 4, 2017

Grails — это отличный маленький фреймворк — как и любой фреймворк, вам нужно узнать, как он работает, прежде чем стать действительно продуктивным, и вам нужно остерегаться слишком большого количества «горячего» кода Groovy, что усложняет поддержку приложения, но я, например, найти это настоящий импульс.

Однако лично я не могу жить без управления зависимостями Maven. Да, я знаю, Айви бла бла бла, но интеграция Ivy IDE — отстой. Так что я действительно с нетерпением ждал Grails 1.1 из-за обещанной поддержки Maven.

Как люди, без сомнения, будут знать, Grails 1.1 вышел недавно. Поэтому я подумал, что возьму поддержку Maven для вращения.

Отправной точкой для любой работы по интеграции Maven / Grails должна стать документация Grails или, точнее, страница интеграции Grails Maven . Здесь все раскроется.

Ну, почти все. Прежде всего вам необходимо настроить файл settings.xml, как указано в документации:


<settings>
  ...
  <pluginGroups>
    <pluginGroup>org.grails</pluginGroup>
  </pluginGroups>
</settings>

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

$ mvn archetype:generate -DarchetypeGroupId=org.grails \
 -DarchetypeArtifactId=grails-maven-archetype  -DarchetypeVersion=1.0 \
 -DarchetypeRepository=http://repository.codehaus.org -DgroupId=com.acme \
 -DartifactId=killerapp

Затем перейдите в каталог вашего нового проекта и инициализируйте структуру проекта Grails 

$ mvn initialize

И о чудо! Полностью вооруженный и действующий проект Grails!

Я могу бегать 

mvn grails:create-domain-class

или

grails create-domain-class

из командной строки, с тем же эффектом. Maven не имеет никакой дополнительной ценности при создании классов Grails, поэтому я бы предпочел последний.

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

Я открываю pom.xml. Уже есть много зависимостей, но Хэмкрест не один из них. Поэтому я добавляю его в конце зависимостей:


<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.5<version>
</dependency>
<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-all</artifactId>
    <version>1.1</version>
</dependency>

Ничего страшного, довольно стандартные вещи Maven. Теперь я добавляю некоторые утверждения Hamcrest к моим модульным тестам Grails:

    void testShouldCheckForMandatoryName() {
        mockDomain(Listing)
        def listing = new Listing(name:null,...)
        assertFalse "validation should have failed", listing.validate()
        assertEquals "nullable", listing.errors.name
    }

становится

    import static org.junit.Assert.*;
    import static org.hamcrest.Matchers.*;
    ...
    void testShouldCheckForMandatoryName() {
    	mockDomain(Listing)
        def listing = new Listing(name:null,...)
        assertThat listing.validate(), is(false)
        assertThat listing.errors.name, is("nullable")
    }

Гораздо приятнее, да? Кстати, если вы используете интеграционные тесты для проверки вашей полевой валидации в Grails 1.1, не используйте вместо этого mockDomain. Этот метод в основном макетирует все методы динамического домена в вашем доменном классе (save (), load (), find (), validate () и т. Д.), Чтобы вы могли проверить свои правила проверки (даже «уникальные») !) к вашему сердцу. Он будет выполнять базовые сохранения, загрузки и удаления, используя закулисный список в памяти (база данных не требуется!). Вы можете узнать о функции mockDomain () и других интересных новых способах тестирования в Grails 1.1 по адресу http://www.grails.org/Testing+Plugin .

На этом этапе, как и следовало ожидать, запуск приложения grails test-app из командной строки больше его не прерывает. Чтобы учесть ваши зависимости, вам нужно запустить mvn test . Это то же самое, за исключением того, что оно добавляет в зависимость и ваши зависимости.

Так как же обстоят дела со средой IDE? Среда IDE NetBeans справляется плохо. Он может видеть, что это проект Grails, но, очевидно, не знает об интеграции Maven / Grails. И вы не можете заставить его открыть проект как проект Maven, а потом рассказать о структуре Grails. Таким образом, вы можете добавить все зависимости, которые вам нравятся, в файл pom.xml, они по-прежнему не будут отображаться в автозаполнении, и среда IDE NetBeans будет жаловаться на отсутствующие классы и пакеты повсюду. Не круто вообще.

IntelliJ справляется намного лучше. Я импортировал проект как проект Maven, и он предложил добавить фасет Grails автоматически. Он может найти все зависимости Maven просто отлично. Выполнение тестов, использующих зависимости Hamcrest, работает нормально — на самом деле, это слишком быстро изнутри IntelliJ (намного быстрее, чем из командной строки).

С http://weblogs.java.net/blog/johnsmart/

29
Share: