Статьи

Пересечение потоков JUnit

Январь 3, 2019

Одна из приятных особенностей миграции JUnit 5 заключается в том, что вы можете запускать тесты JUnit 4 в винтажном режиме, и все по-прежнему совместимо. Одним из недостатков является то, что некоторые из аннотаций и методов имеют одинаковые имена в JUnit 4 и JUnit 5, и очень легко, когда доступны оба набора библиотечных зависимостей, импортировать неправильный материал и создать тест, который не сделать работу.

Однако хуже, когда тест, который не имеет смысла, также не провалит сборку.

Рассмотрим этот тест:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
import org.junit.Test;
import org.junit.jupiter.api.BeforeEach;
 
import static org.junit.Assert.assertEquals;
 
public class AccidentalJUnit4Test {
    @BeforeEach
    public void beforeEach() {
 
    }
 
    @Test
    public void test() {
        assertEquals(1, 1);
    }
}

Это какой-то ужасный суп из аннотаций JUnit 5 и JUnit 4. Он работает в IDE, но в сборке maven он игнорируется, поскольку @Test от неправильного JUnit и у меня не работает junit-vintage .

Так запустить junit-vintage ?

Как это произошло?

В моем случае я импортировал интеграцию TestContainers для JUnit 5, которая имеет транзитивные зависимости, в JUnit 4. Это не здорово, но это не конец света. Однако я хочу, чтобы в моем коде были только тесты JUnit 5, и все же я могу случайно написать тесты с JUnit 4 битами, и никто не заметит!

Эти наполовину сформированные тесты никогда не предназначались, поэтому я хочу, чтобы они не прошли сборку.

Что не работает

  • Checkstyle — checkstyle может сканировать запрещенные операторы import , но я не сканирую src/test с ним, и правила checkstyle для нашего проекта используются совместно с другим проектом, который junit-vintage использует junit-vintage .
  • Макер — сложный сканер, который, кажется, не имеет ответа из коробки
  • Enforcer — это помешало бы мне включить зависимость JUnit 4 … за исключением того, что я не могу не допустить этого

Почему я должен волноваться?

Делать вещи доказательством ошибки, добавляя автоматизацию, чтобы выявлять известные ошибки и сообщать вам о них, гораздо лучше, чем оставлять предупреждения повсюду, но ошибка все еще возможна.

Это как когда кто-то ставит знак, предупреждающий, что вода очень горячая, а не вода нужной температуры!

Все, что может дать нам принудительную функцию, является преимуществом.

Что работает

Я нашел глупый и простой ответ на этот вопрос на GitHub.

Этот плагин Maven Grep хорошо работает:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<build>
    <plugins>
      <!-- grep maven plugin set to filter naughty JUnit4 stuff -->
      <plugin>
        <groupId>net.radai</groupId>
        <artifactId>grep-maven-plugin</artifactId>
        <version>1.1</version>
        <executions>
          <execution>
            <goals>
              <goal>grep</goal>
            </goals>
            <phase>test</phase>
            <configuration>
              <greps>
                <grep>
                  <failIfFound>true</failIfFound>
                  <filePattern>src/test/java/**/*.java</filePattern>
                  <grepPattern>import\s+(static\s+)?org\.junit\.(Assert|Test|Before|After|AfterClass|Assume|BeforeClass|ClassRule|Rule|FixMethodOrder|Ignore|Rule)</grepPattern>
                  <outputPattern>Found JUnit 4 imports in file ${fileName} at line ${lineNumber} : ${line}</outputPattern>
                </grep>
              </greps>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
 
<!-- you also need to add the distribution repo -->
  <pluginRepositories>
    <pluginRepository>
      <id>ossrh</id>
      <url>https://oss.sonatype.org/content/groups/public</url>
    </pluginRepository>
  </pluginRepositories>

Вышесказанное сработает для меня, чтобы предотвратить ошибку, это может сработать для вас.

Я поместил работающий (ну, не удалось по правильным причинам) пример вышеупомянутого кода в GitHub .

Кредит, где он должен

Я чуть не отказался от вышеуказанной проблемы. К счастью, сообщество open source просто великолепно.

Radai Rosenblatt написал этот плагин в 2016 году. Сотрудник по имени Michal Lozinski добавил сканирование файловых шаблонов в 2017 году.

Когда мы впервые попробовали использовать вышеуказанную конфигурацию, она не работала. Документы не описывают, как это сделать, но чтение кода плагина показало, что можно использовать filePattern . Однако это не сработало.

Я связался с Радаем сегодня, и он обновил выпуск плагина, и теперь он работает.

Без открытого исходного кода это было бы невозможно. Без авторов, принимающих на себя ответственность за оказание помощи незнакомцам, это было бы невозможно.

Благодаря!!!

Смотрите оригинальную статью здесь: Пересечение потоков JUnit

Мнения, высказанные участниками Java Code Geeks, являются их собственными.

44
Share: