Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Ооо, спасибо. Много полезного.
А Вы наследуетесь от
А Вы наследуетесь от
Assert просто чтобы импорты не писать?
Лично я считаю назвать метод тестирующий заполнение адреса как testPopulateAddress более наглядно чем просто populateAddress — здесь приставка test несет смысловую нагрузку.
Смысловую нагрузку уже несет @Test, поэтому не очень понятно, зачем повторять это слово в имени метода кроме как по привычке или для совместимости.
В данном примере приставка test говорит, что метод именно тестирует заполнение адреса и, как прочая дополнительная информация в названии, «говорит, что конкретно там происходит». Без нее можно подумать, что метод используется только для заполнения адреса. И даже с дополнительной смысловой нагрузкой (как, к примеру, в посте ниже populatesAdressWhenHostIsGiven) при просмотре листинга методов в IDE (тем более если их много) нельзя точно сказать что это за метод — вспомогательный для заполнения адреса или же метод, который тестирует заполнение адреса.
что testPopulateAdress, что populateAdress — оба варианта так себе. Слово тест в начале никак его не красит. А вот название, к примеру, populatesAdressWhenHostIsGiven — уже ближе к правде будет.
Я вообще запускаюсь с помощью спринговой запускалки. Очень полезная вещь с учетом того что очень много проектов пишется с учетом конфигурирования на спринге. Очень легко конфигурируется эта связка.
Ну если уже захотелось написать тесты, то использовать надо TestNG. Он годиться как для юнитестов, так и для integration and system tests. TestNG может запускать тесты в разных threads, устанавливать зависимости между тестами и параметризация сделана намного глубже чем junit4.
вот написал бы кто-н подробно, чем ТестНГ лучше — было бы интересно почитать
пока что про потоки, зависимости и параметризации не очень убедительно
пока что про потоки, зависимости и параметризации не очень убедительно
TestNG современный testing framework. JUnit старай рабочая лошадка на котором написано миллионы юнитестов, но JUnit 3 морально устарел, а JUnit 4 это жалкая попытка добавить отсутствующий функционал.
В JUnit каждый юнитест абсолютно не зависим, что в реальной жизни не всегда удобно, в результате разработчики хранят общий контекст в static variables. В TestNG есть зависимость и порядок выполнения между юнитестами а также возможность передавать контекст из теста в тест. Советую прочитать testng.org/doc/documentation-main.html — всего одна страница.
В JUnit каждый юнитест абсолютно не зависим, что в реальной жизни не всегда удобно, в результате разработчики хранят общий контекст в static variables. В TestNG есть зависимость и порядок выполнения между юнитестами а также возможность передавать контекст из теста в тест. Советую прочитать testng.org/doc/documentation-main.html — всего одна страница.
Я не могу придумать ни единого валидного случая, когда мне бы захотелось сделать тесты зависимыми друг от друга.
Это только в идеальных условиях тесты могут быть независимые или простые юнитесты. А integration или system тесты имеют определенный порядок, так как проверяют сложные сценарии. Даже в обычных юнитестах скажем для DAO Layer проще проверять CRUD операции последовательно Create / Update / Remove в разных тест мотодах. Иначе 90% кода в каждом юнитесте уходит на подготовку данных для теста. Я исключаю крайности когда все Assert-ы находятся в одном @Test методе. Best Practice чтобы было много мелких методов.
Пример — в статье рассмотрена утилита, проверяющая строку на пустоту. Допустим есть сервис, который что-то делает, что-то таинственное, использует при этом эту утилиту, где то в коде использует проверку на пустоту. Естественно, если не будет работать утилита, то не будет работать и сервис, тест сервиса зависит от теста утилиты.
Зачем тесту готовить для себя данные когда сама подготовка данных может быть юнит-тестом?
Спасибо большое, но мне как новичку хотелось бы больше практики. То есть:
В экслипсе надо заранее создать отдельный source folder для тестов чтобы не мешать их с кодом, так? Я всё правильно делаю? А как ему объяснить, что я не хочу экспортировать тесты вместе с кодом? В Order and Export папка с тестами не убирается, при экспорте тоже настроек нет. Или мне нужно вот только для этого срочно изучать Ant?
А как попросить экслипса прогонять тесты перед запуском приложения из него же? Ведь они для этого нужны и этого мы хотели, чтобы сразу видеть что сломалось, разве не так?
В моём методе есть обычный assert. Попробовал его потестировать с @Test(expected = AssertionError.class)
Не проходит… говорит java.lang.AssertionError: Expected java.lang.AssertionError. То есть AssertionError не совместим с JUnit? А какие ещё исключения/ограничения? Их много?
Если поставить -ea в запускалку JUnit'а, то вообще все тесты вот так валятся… о_О
Про TestNG напишите пожалуйста :)
В экслипсе надо заранее создать отдельный source folder для тестов чтобы не мешать их с кодом, так? Я всё правильно делаю? А как ему объяснить, что я не хочу экспортировать тесты вместе с кодом? В Order and Export папка с тестами не убирается, при экспорте тоже настроек нет. Или мне нужно вот только для этого срочно изучать Ant?
А как попросить экслипса прогонять тесты перед запуском приложения из него же? Ведь они для этого нужны и этого мы хотели, чтобы сразу видеть что сломалось, разве не так?
В моём методе есть обычный assert. Попробовал его потестировать с @Test(expected = AssertionError.class)
Не проходит… говорит java.lang.AssertionError: Expected java.lang.AssertionError. То есть AssertionError не совместим с JUnit? А какие ещё исключения/ограничения? Их много?
Если поставить -ea в запускалку JUnit'а, то вообще все тесты вот так валятся… о_О
Про TestNG напишите пожалуйста :)
Да, в планах продолжения по TestNG, Spock Framework, инструментарий maven-а, и д.р. Материала много, было бы время :)
Эээ, а может Вы как старший товарищ ещё и на вопросы про эклипс ответите? Если Вы им пользуетесь, то наверняка ж знаете, а я всё нужные кнопки найти не могу…
Хотя бы как тесты автоматом при запуске прогонять… А то толку от них не будет жн, если их не гонять.
В Eclipse тесты автоматом обычно не гоняют. Что поменял — то и запустил.
Есть плагины, которые умеют запускать автоматом: Infinitest и JUnitMax. Здесь их сравнение:
www.benrady.com/2009/04/comparing-infinitest-and-junitmax.html
Есть плагины, которые умеют запускать автоматом: Infinitest и JUnitMax. Здесь их сравнение:
www.benrady.com/2009/04/comparing-infinitest-and-junitmax.html
Извините, с эклипсом мало знаком, но тут другое, можете попытаться отлавливать Throwable ;)
Насчет прогона тестов, чаще всего пользуюсь мавеном из терминала, иногда дебаг под идеей.
Насчет прогона тестов, чаще всего пользуюсь мавеном из терминала, иногда дебаг под идеей.
> В экслипсе надо заранее создать отдельный source folder для тестов чтобы не мешать их с кодом, так? Я всё правильно делаю? А как ему объяснить, что я не хочу экспортировать тесты вместе с кодом? В Order and Export папка с тестами не убирается, при экспорте тоже настроек нет. Или мне нужно вот только для этого срочно изучать Ant?
А как попросить экслипса прогонять тесты перед запуском приложения из него же? Ведь они для этого нужны и этого мы хотели, чтобы сразу видеть что сломалось, разве не так?
Попробуйте изучить maven :) Потратите два дня максимум, зато потом до конца жизни будете радоваться. Думаю, в maven есть все ответы на ваши вопросы.
> В моём методе есть обычный assert. Попробовал его потестировать с @Test(expected = AssertionError.class)
Не проходит… говорит java.lang.AssertionError: Expected java.lang.AssertionError. То есть AssertionError не совместим с JUnit? А какие ещё исключения/ограничения? Их много?
Если поставить -ea в запускалку JUnit'а, то вообще все тесты вот так валятся… о_О
JUnit поддерживает обычные assert'ы. Уберите expected и всегда включайте ключик -ea. Если assert нарушится, то тест упадет и JUnit это зафиксирует.
А как попросить экслипса прогонять тесты перед запуском приложения из него же? Ведь они для этого нужны и этого мы хотели, чтобы сразу видеть что сломалось, разве не так?
Попробуйте изучить maven :) Потратите два дня максимум, зато потом до конца жизни будете радоваться. Думаю, в maven есть все ответы на ваши вопросы.
> В моём методе есть обычный assert. Попробовал его потестировать с @Test(expected = AssertionError.class)
Не проходит… говорит java.lang.AssertionError: Expected java.lang.AssertionError. То есть AssertionError не совместим с JUnit? А какие ещё исключения/ограничения? Их много?
Если поставить -ea в запускалку JUnit'а, то вообще все тесты вот так валятся… о_О
JUnit поддерживает обычные assert'ы. Уберите expected и всегда включайте ключик -ea. Если assert нарушится, то тест упадет и JUnit это зафиксирует.
Требую добавления в статью обзора stub/mock-фреймворков: без них unit-тестирование вовсе не unit!
p.s. А в остальном отлично;)
p.s. А в остальном отлично;)
Вроде бы в книге «Продутивный Программист» Нила Форда по поводу имен тестовых методов я прочитал хороший совет, которым пользуюсь. Суть в том, что для имен тестовых методов можно сделать исключение и писать их через подчеркивание, например:
publiс void check_if_empty_list_is_not_raised_exception() {...}
Так имена тестовых методов становятся гораздо более читаемыми.
publiс void check_if_empty_list_is_not_raised_exception() {...}
Так имена тестовых методов становятся гораздо более читаемыми.
Хорошая статья. Могу еще добавить от себя пару фишек JUnit.
1. Классы из пакета org.hamcrest, в частности Matcher и его подклассы. Позволяют много чего.
Например,
2. Из правил могу добавить ErrorCollector — позволяет накапливать ошибки в ассертах. Полезно, когда нужно видеть сразу все места, где упал тест, а не только первый assert
3. Класс JUnit4TestAdapter — позволяет запускать JUnit4 тесты в JUnit3 стиле, т.е. через TestCase. Полезно, когда среда тестирования не поддерживает JUnit4, например JUnitEE или Apache Cactus.
Пример:
1. Классы из пакета org.hamcrest, в частности Matcher и его подклассы. Позволяют много чего.
Например,
assertThat(obj, instanceOf(A.class)) — проверка, что obj — экземпляр класса AassertThat(list.size(), not(0)) — проверка, что list.size() не равен нулю2. Из правил могу добавить ErrorCollector — позволяет накапливать ошибки в ассертах. Полезно, когда нужно видеть сразу все места, где упал тест, а не только первый assert
3. Класс JUnit4TestAdapter — позволяет запускать JUnit4 тесты в JUnit3 стиле, т.е. через TestCase. Полезно, когда среда тестирования не поддерживает JUnit4, например JUnitEE или Apache Cactus.
Пример:
public class SampleTestSuite
{
public static Test suite()
{
TestSuite suite = new TestSuite("Sample Tests");
suite.addTest(new JUnit4TestAdapter(SampleTest1.class));
suite.addTest(new JUnit4TestAdapter(SampleTest2.class));
return suite;
}
}
создать Suite с помощью JUnit — редкий гемморой. Пришлось даже написать небольшой велосипед для этого
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование в Java. JUnit