Java в примерах для начинающих
Хороший юнит-тест написать легко, плохой — ещё проще. Плохой юнит тест ничего не проверяет. То есть конечно что-то с чем-то сравнивается, какое-то поведение проверяется, но…стоит поменять что-нибудь в тесте, как ничего не происходит. Я уже писал, что признаком проблемы с Читать далее Как не надо писать модульные тесты
В статьях о JUnit я использовал в качестве примеров простые самодостаточные классы, которые не имели никаких зависимостей. На практике такие классы встречаются редко: обычно класс, выполняющий хоть какие-либо действия, зависит от других классов. Примером может служить классическая архитектура с многослойными приложениями, когда один Читать далее Hello, EasyMock!
Чтобы написать хороший юнит-тест, надо задать критерии его хорошести и придерживаться их. Это, вообще, относится к любой области деятельности: определяем цель, движемся к ней, если результат совпал с целью, значит всё удалось 🙂 Признаки хорошего юнит-теста Тест должен проваливаться, когда Читать далее Как написать хороший юнит-тест
Параметризованные тесты, предположения, теории и правила покрывают 95% всего необходимого для написания юнит-тестов функционала. Оставшимися пять процентами занимается тяжёлая артиллерия: собственные test runners. Подготовка Для иллюстрации возьмём LocalizedDateService из примера с предположениями и перепишем его, чтобы проверять значения для нескольких локалей. Строго говоря, Читать далее Runners
Код, который содержит циклы или рекурсию, может, при определённых условиях, исполняться бесконечно долго. Ещё встречается код, который должен выполняться фиксированное время. Хороший пример такого кода — генерация виджета персональных новостей на крупном сайте. Он должен выполниться за определённое время, скажем 10 Читать далее Таймауты
Правила (Rules) JUnit позволяют влиять на поведение и исполнение всех тестов в классе. Правило представляет собой код, исполняющийся «вокруг» тестового метода, для каждого такого метода, позволяя расширять и переделывать поведение JUnit каким угодно образом. Собственное правило Возьмём код из примера с предположениями и Читать далее Правила
Обычно юнит-тесты пишутся как можно более независимыми. Мы стараемся сделать их устойчивыми к изменениям окружения, порядка выполнения, стороннего кода и так далее. Цель юнит-тестирования это фиксирование поведения кода, находящегося в изоляции. Но в реальности бывает нужно проверять код только при соблюдении каких-либо Читать далее Предположения и теории
При написании unit тестов часто возникает необходимость проводить абсолютно идентичные испытания кода с разными данными. Примером такого кода может быть вычисление квадратного корня — для входных данных выше нуля мы ожидаем получить значения корня, а при передаче числа меньше 0, Читать далее Параметризованные тесты
Иногда хочется взять и пропустить тот или иной юнит-тест, который всё время проваливается. Можно, конечно, его закоментировать, но это не так удобно. Во-первых, закомментированный тест перестанет компилироваться и, если когда Ваш код сильно изменится, вернуть тест к жизни будет сложнее. Во-вторых, про этот тест Читать далее Игнорирование тестов
До сих пор мы тестировали только корректное поведение кода (happy path) — проверяли корректную работу на корректных данных. Такой идеальный мир, к сожалению, встречается только в учебниках, да и то, не во всех. Реальный код сталкивается с кривыми руками программистов данными и Читать далее Тестирование исключений