JUnit 4.9 зарелизило

    Несколько часов назад на github-е популярного TDD-фреймворка JUnit появилась финальная версия JUnit 4.9. Что же вошло в долгожданный релиз?

    Новые Правила


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

    И да, все производные от ParentRunner включая действующий по-умолчанию BlockJUnit4ClassRunner корректно обрабатывают новый вид правил.

    Пример тестовой сюиты, которая создает соединение с сервером один единственный раз и закрывает его после выполнения всех тестов сюиты:

    <br/>@RunWith(Suite.class)<br/>@SuiteClasses({A.class, B.class, C.class})<br/>public class UsesExternalResource {<br/>    public static Server myServer= new Server();<br/> <br/>    @ClassRule<br/>    public static ExternalResource resource= new ExternalResource() {<br/>        @Override<br/>        protected void before() throws Throwable {<br/>            myServer.connect();<br/>        };<br/> <br/>        @Override<br/>        protected void after() {<br/>            myServer.disconnect();<br/>        };<br/>    };<br/>}<br/> <br/>
    Хозяйке на заметку: в свете данных нововведений прежний интерфейс MethodRule устарел и получил статус deprecated. Разработчикам Правил следует работать с новым интерфейсом TestRule, чтобы дать возможность применять их как с @Rule так и с @ClassRule.

    Правила в комплекте JUnit 4.9 в большинстве своем уже переехали на новый интерфейс. Для большинства пользователей смена API по-идее пройдет незаметно и не потребует изменений в существующих тестах.

    Maven – теперь официально


    До сих пор сборкой пакетов для Maven занимались анонимные добровольцы и качество результатов оставляло желать лучшего. Начиная с версии 4.9 команда разработчиков JUnit перенимает эту задачу на себя. Замечу, однако, что судя по сорцам официальная сборка JUnit по-прежнему происходит в Ant. Будем надеяться, что ребята, все-же справятся с новой задачей грамотно и не наступят, к примеру, на старые грабли с транзитивной зависимостью пакета junit-dep от hamcrest-core (который до сих пор приходится выпиливать exclusion-ом).

    Что еще?


    Помимо косметических изменений в структуре проекта (текст GPL теперь часть сорцов, Ant-сборка теперь быстрее) были пофиксены серьезные баги:

    — github#98: assumeTrue() does not work with expected exceptions
    — github#74: Categories + Parameterized
    — github#38: ParentRunner filters more than once
    — github#248: protected BlockJUnit4ClassRunner#rules method removed from 4.8.2
    — github#187: Accidental dependency on Java 6
    — github#163: Bad comparison failure message when using assertEquals(String, String)
    — github#227: ParentRunner now assumes that getChildren() returns a modifiable list

    Вместо заключения


    Список изменений в целом оправдывает minor-release. Выражаю разработчикам глубокую благодарность за их безвозмездный вклад в повышение качества кода и поздравляю хабровчан с хорошей новостью.

    Комментарии 6

      0
        +1
        Впервые слышу про правила(Rule) в JUnit! Спасибо за пост, а то так бы и не узнал о них! :-) Пойду изучать…
          +1
          Отлично, что mvn станет официально поддерживаемым тулом.
            –2
            TestNG?
              0
              Класс!

              А зачем вы выпиливаете зависимость от hamcrest-core? Это же классная либа! Вот тут есть примеры, как можно его использовать, начиная с версии JUnit 4.4: http://junit.sourceforge.net/doc/ReleaseNotes4.4.html
                +2
                Я очень люблю hamcrest, и именно по этой причине предпочитаю полноценный пакет hamcrest-all базовому пакету hamcrest-core. Но если добавить в classpath одновременно обе библиотеки, то получим очень неприятные конфликты времени исполнения.

                Именно это происходит, если в classpath есть org.hamcrest:hamcrest-all и junit:junit, т.к. последний уже содержит в себе некоторые hamcrest-классы.

                Разработчики JUnit советуют вкупе с hamcrest-all использовать исключительно пакет junit:junit-dep, который не содержит в себе hamcrest классов. Maven кофиг выглядит примерно так:

                <dependency>
                  <groupId>junit</groupId>
                  <artifactId>junit-dep</artifactId>
                  <version>${version.junit}</version>
                  <scope>test</scope>
                </dependency>
                <dependency>
                  <groupId>org.hamcrest</groupId>
                  <artifactId>hamcrest-all</artifactId>
                  <version>${version.hamcrest}</version>
                  <scope>test</scope>
                </dependency>



                Но тут есть подвох: пакет junit-dep имеет compile-scope зависимость от пакета hamcrest-core, хотя логичнее был бы provided-scope. Как следствие, в class-path попадают не два, а три пакета:

                • junit-dep-4.9
                • hamcrest-core-1.1
                • hamcrest-all-1.2

                со всеми вытекающими последствиями.

                Единственное противоядие от недуга, «выпиливать» ненужный hamcrest-core в ненужной, устаревшей версии. Примерно так:

                <dependency>
                  <groupId>junit</groupId>
                  <artifactId>junit-dep</artifactId>
                  <version>${version.junit}</version>
                  <scope>test</scope>
                  <exclusions>
                    <exclusion>
                      <groupId>org.hamcrest</groupId>
                      <artifactId>hamcrest-core</artifactId>
                    </exclusion>
                  </exclusions>
                </dependency>
                <dependency>
                  <groupId>org.hamcrest</groupId>
                  <artifactId>hamcrest-all</artifactId>
                  <version>${version.hamcrest}</version>
                  <scope>test</scope>
                </dependency>




                p.s. мои опасения насчет 4.9 подтвердились. hamcrest-core по-прежнему включен в compile-scope пакета junit-dep. Видимо придется писать команде баг-репорт, благо ребята сами вызвались поддерживать maven пакеты…

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

              Самое читаемое