Java в примерах для начинающих
Параметризованные тесты, предположения, теории и правила покрывают 95% всего необходимого для написания юнит-тестов функционала. Оставшимися пять процентами занимается тяжёлая артиллерия: собственные test runners. Подготовка Для иллюстрации возьмём LocalizedDateService из примера с предположениями и перепишем его, чтобы проверять значения для нескольких локалей. Строго говоря, Читать далее Runners
Код, который содержит циклы или рекурсию, может, при определённых условиях, исполняться бесконечно долго. Ещё встречается код, который должен выполняться фиксированное время. Хороший пример такого кода — генерация виджета персональных новостей на крупном сайте. Он должен выполниться за определённое время, скажем 10 Читать далее Таймауты
Правила (Rules) JUnit позволяют влиять на поведение и исполнение всех тестов в классе. Правило представляет собой код, исполняющийся «вокруг» тестового метода, для каждого такого метода, позволяя расширять и переделывать поведение JUnit каким угодно образом. Собственное правило Возьмём код из примера с предположениями и Читать далее Правила
Обычно юнит-тесты пишутся как можно более независимыми. Мы стараемся сделать их устойчивыми к изменениям окружения, порядка выполнения, стороннего кода и так далее. Цель юнит-тестирования это фиксирование поведения кода, находящегося в изоляции. Но в реальности бывает нужно проверять код только при соблюдении каких-либо Читать далее Предположения и теории
При написании unit тестов часто возникает необходимость проводить абсолютно идентичные испытания кода с разными данными. Примером такого кода может быть вычисление квадратного корня — для входных данных выше нуля мы ожидаем получить значения корня, а при передаче числа меньше 0, Читать далее Параметризованные тесты
Иногда хочется взять и пропустить тот или иной юнит-тест, который всё время проваливается. Можно, конечно, его закоментировать, но это не так удобно. Во-первых, закомментированный тест перестанет компилироваться и, если когда Ваш код сильно изменится, вернуть тест к жизни будет сложнее. Во-вторых, про этот тест Читать далее Игнорирование тестов
До сих пор мы тестировали только корректное поведение кода (happy path) — проверяли корректную работу на корректных данных. Такой идеальный мир, к сожалению, встречается только в учебниках, да и то, не во всех. Реальный код сталкивается с кривыми руками программистов данными и Читать далее Тестирование исключений
Из коробки JUnit предлагает некоторое количество assert* методов, позволяющих проверить состояние объекта. Но эти примитивные методы не позволяют написать комплексных проверок, например «значение эквивалентно X или является null» или «Значение объекста эквивалентно X и значение его свойства Z эквивалетно Y» итд. В современных версиях JUnit Читать далее Matchers
При написании тестов, даже самых простых, зачастую используются тестовые объекты. Например в статье про основные возможности JUnit я регулярно использовал следующую конструкцию:
|
1
2
|
String[] expected = {"T", "E", "S", "T"};
String source="T:E:S:T";
|
Что не совсем хорошо: во-первых, это нарушает принцип DRY — Don’t Repeat Yourself (не повторяй себя); во-вторых, если б Читать далее Подготовка тестовых объектов
Юнит-тестирование (модульное тестирование) есть автоматизированное тестирование отдельных функций/классов в независимом окружении, то есть без использования сторонних классов или функций, от которых проверямый код зависит. Идея состоит в том, чтобы убедиться в постоянности поведения самого класса/функции, а не в том, как он взаимодействует с другим Читать далее Hello, JUnit!