Comments 6
Впервые слышу про правила(Rule) в JUnit! Спасибо за пост, а то так бы и не узнал о них! :-) Пойду изучать…
+1
Отлично, что mvn станет официально поддерживаемым тулом.
+1
TestNG?
-2
Класс!
А зачем вы выпиливаете зависимость от hamcrest-core? Это же классная либа! Вот тут есть примеры, как можно его использовать, начиная с версии JUnit 4.4: http://junit.sourceforge.net/doc/ReleaseNotes4.4.html
А зачем вы выпиливаете зависимость от hamcrest-core? Это же классная либа! Вот тут есть примеры, как можно его использовать, начиная с версии JUnit 4.4: http://junit.sourceforge.net/doc/ReleaseNotes4.4.html
0
Я очень люблю hamcrest, и именно по этой причине предпочитаю полноценный пакет hamcrest-all базовому пакету hamcrest-core. Но если добавить в classpath одновременно обе библиотеки, то получим очень неприятные конфликты времени исполнения.
Именно это происходит, если в classpath есть
Разработчики JUnit советуют вкупе с hamcrest-all использовать исключительно пакет junit:junit-dep, который не содержит в себе hamcrest классов. Maven кофиг выглядит примерно так:
Но тут есть подвох: пакет
со всеми вытекающими последствиями.
Единственное противоядие от недуга, «выпиливать» ненужный hamcrest-core в ненужной, устаревшей версии. Примерно так:
p.s. мои опасения насчет 4.9 подтвердились.
Именно это происходит, если в 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 пакеты… +2
Only those users with full accounts are able to leave comments. Log in, please.
JUnit 4.9 зарелизило