Настройка состава JUnit5 тестов с помощью application.properties

[sshikov]

А не проще на TestNG перейти? Не, ну реально — что есть в JUnit такого, чего нет в TestNG?

Ассерты все равно удобнее на hamcrest писать.

А группы тестов там есть (насколько я помню — давно), они включаются и выключаются при запуске.

[bvn13]

«Перейти» не всегда проще.

К тому же, некоторые статьи пишутся для proof of concept.

[sshikov]

>Перейти» не всегда проще.
Вы не поверите — я пробовал. TestNG появился в 2004 — вот тогда же и попробовал. Вот посмотрите на этот код, и скажите мне, отличается ли он чем-то от JUnit?

package example1;
 
import org.testng.annotations.*;
 
public class SimpleTest {
 
 @BeforeClass
 public void setUp() {
   // code that will be invoked when this test is instantiated
 }
 
 @Test(groups = { "fast" })
 public void aFastTest() {
   System.out.println("Fast test");
 }
 
 @Test(groups = { "slow" })
 public void aSlowTest() {
    System.out.println("Slow test");
 }
 
}

На мой взгляд — практически ничем, кроме разве что набора аннотаций. При этом группы, как вы видите, тут есть из коробки. Если вы пользуетесь не чем-то экзотическим, то например maven эти тесты будет запускать точно так же, как и запускал. Включить и отключить можно из командной строки.

proof of concept — ну это вполне понятно, даже ради удовлетворения любопытства. Я в общем-то и хочу понять, дает ли это в итоге что-то принципиально такое, чего не было ранее, уже много лет?

[Kanut]

С «перейти» бычно проблема в «легаси», которое существует на момент перехода.

[sshikov]

С легаси — то есть с написанными тестами? Ну понятно, что усилия придется потратить. Ну так предлагаемое решение — оно ведь тоже далеко не бесплатное. @TestEnabled(property = «first») — оно ведь само в код не добавится, его нужно ручками вписать везде где нужно. И никакая IDE за нас не решит, где именно нам нужно.

На первый взгляд — усилия сопоставимые. Впрочем, я никого не агитирую, хотя TestNG — хорошая, проверенная временем штука.

[Kanut]

Скажем так: у меня есть опыт работы с несколькими юнит-тест-фреймворками в одном проекте и повторять его я не особо хочу:)

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

Перейти» не всегда проще.

:)

[sshikov]

>Скажем так: у меня есть опыт работы с несколькими юнит-тест-фреймворками в одном проекте
У меня тоже. Негативных эффектов не припомню (но агитировать просто так ради развлечения — не стану тоже. Оно того не стоит — эти фреймворки на мой взгляд почти равноценны). Я бы еще подумал, если бы второй фреймворк был скажем типа property based, ну или что-то типа мутаций тестов бы делал. Тогда может быть была бы некая польза.

>Перейти не всегда проще.

Так я не спорю с этим утверждением в целом. Я просто оценил на глаз для частного случая стоимость того и другого. Выглядит примерно одинаково. Я запросто мог чего-то не учесть, но опыт перехода на TestNG у меня был тоже — и такой переход совсем не сложный, особенно если мы можем в спокойной обстановке переводить один тест за другим.

Более того (цитирую документацию):

TestNG can automatically recognize and run JUnit tests, so you can use TestNG as a runner for all your existing tests and write new tests using TestNG.

Ну то есть, в оптимистичном случае переписывать вообще не нужно. Но это не я вам обещал, а Цедрик ;)

[orthanner]

Хм, Spring Boot… а почему не используем SpringRunner и @IfProfileValue?

[bvn13]

@IfProfileValue не используется, потому что:

app.skip.test.third=false

@IfProfileValue(name = "app.skip.test.third", value = "true")
    @Test
    public void testThird() {
        assertTrue(false);
    }

Результат:

org.opentest4j.AssertionFailedError: expected: <true> but was: <false>

А SpringRunner же нужен для автовайринга. Для демо-примера не используется.