Comments 9
А не проще на TestNG перейти? Не, ну реально — что есть в JUnit такого, чего нет в TestNG?
Ассерты все равно удобнее на hamcrest писать.
А группы тестов там есть (насколько я помню — давно), они включаются и выключаются при запуске.
Ассерты все равно удобнее на hamcrest писать.
А группы тестов там есть (насколько я помню — давно), они включаются и выключаются при запуске.
«Перейти» не всегда проще.
К тому же, некоторые статьи пишутся для proof of concept.
К тому же, некоторые статьи пишутся для proof of concept.
>Перейти» не всегда проще.
Вы не поверите — я пробовал. TestNG появился в 2004 — вот тогда же и попробовал. Вот посмотрите на этот код, и скажите мне, отличается ли он чем-то от JUnit?
На мой взгляд — практически ничем, кроме разве что набора аннотаций. При этом группы, как вы видите, тут есть из коробки. Если вы пользуетесь не чем-то экзотическим, то например maven эти тесты будет запускать точно так же, как и запускал. Включить и отключить можно из командной строки.
proof of concept — ну это вполне понятно, даже ради удовлетворения любопытства. Я в общем-то и хочу понять, дает ли это в итоге что-то принципиально такое, чего не было ранее, уже много лет?
Вы не поверите — я пробовал. 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 — ну это вполне понятно, даже ради удовлетворения любопытства. Я в общем-то и хочу понять, дает ли это в итоге что-то принципиально такое, чего не было ранее, уже много лет?
С «перейти» бычно проблема в «легаси», которое существует на момент перехода.
С легаси — то есть с написанными тестами? Ну понятно, что усилия придется потратить. Ну так предлагаемое решение — оно ведь тоже далеко не бесплатное. @TestEnabled(property = «first») — оно ведь само в код не добавится, его нужно ручками вписать везде где нужно. И никакая IDE за нас не решит, где именно нам нужно.
На первый взгляд — усилия сопоставимые. Впрочем, я никого не агитирую, хотя TestNG — хорошая, проверенная временем штука.
На первый взгляд — усилия сопоставимые. Впрочем, я никого не агитирую, хотя TestNG — хорошая, проверенная временем штука.
Скажем так: у меня есть опыт работы с несколькими юнит-тест-фреймворками в одном проекте и повторять его я не особо хочу:)
А дальше всё зависит от того сколько старых юнит-тестов надо переписать и сколько проперти-атрибутов надо добавить в код. И если соотношение несколько тысяч к нескольким десяткам, то, процитирую ещё раз:
:)
А дальше всё зависит от того сколько старых юнит-тестов надо переписать и сколько проперти-атрибутов надо добавить в код. И если соотношение несколько тысяч к нескольким десяткам, то, процитирую ещё раз:
Перейти» не всегда проще.
:)
>Скажем так: у меня есть опыт работы с несколькими юнит-тест-фреймворками в одном проекте
У меня тоже. Негативных эффектов не припомню (но агитировать просто так ради развлечения — не стану тоже. Оно того не стоит — эти фреймворки на мой взгляд почти равноценны). Я бы еще подумал, если бы второй фреймворк был скажем типа 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.
Ну то есть, в оптимистичном случае переписывать вообще не нужно. Но это не я вам обещал, а Цедрик ;)
У меня тоже. Негативных эффектов не припомню (но агитировать просто так ради развлечения — не стану тоже. Оно того не стоит — эти фреймворки на мой взгляд почти равноценны). Я бы еще подумал, если бы второй фреймворк был скажем типа 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.
Ну то есть, в оптимистичном случае переписывать вообще не нужно. Но это не я вам обещал, а Цедрик ;)
Хм, Spring Boot… а почему не используем SpringRunner и @IfProfileValue?
@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 же нужен для автовайринга. Для демо-примера не используется.
Sign up to leave a comment.
Настройка состава JUnit5 тестов с помощью application.properties