Unit-тестированиеЧитать полностью »
Рубрика «mockito»
Unit-тестирование — мастхэв?
2024-12-04 в 5:12, admin, рубрики: java, java junior, junit, mockito, testng, Unit-тестирование, бекенд, пет-проектыRecord-and-Replay тестирование — сочетание достоинств юнит и интеграционных тестов
2021-08-22 в 12:10, admin, рубрики: java, mockito, tdd, wiremock, интеграционное тестирование, тестирование, Тестирование IT-систем, Тестирование веб-сервисов, тесты, юнит-тесты
Mockito и как его готовить
2019-03-23 в 15:11, admin, рубрики: java, mockito, автотестирование, заглушки, Тестирование IT-системО статье
Перед вами очередное руководство по Mockito. В нём я, с одной стороны, попытался описать функционал этой библиотеки так, чтобы незнакомый с нею читатель сразу получил возможность полноценно ею пользоваться, а не только общее представление о ней. С другой — я хотел сделать его достаточно компактным и структурированным, чтобы можно было быстро прочесть его целиком и быстро найти в нём что-то единожды прочитанное, но подзабытое. В общем, эта такая статья, какая бы пригодилась мне самому, когда я только столкнулся с этой библиотекой и не очень понимал, как она работает.
Полагаю, она и сейчас может пригодиться мне же — иногда я забываю что-то из этого, а вспоминать материал удобнее всего не по официальной документации или чужим статьям, а по собственному, скажем так, конспекту. Вместе с тем я старался построить текст так, чтобы он был удобен прежде всего для знакомства с Mockito с нуля, и кое-где подробно разбираю вроде бы очевидные вещи — не все из которых были для меня очевидными с самого начала.
Пирамида тестов на практике
2018-05-20 в 11:38, admin, рубрики: CDC-тесты, devops, Galen, headless-браузер, json, junit, mockito, pact, REST-assured, selenium, solid, spring, tdd, wiremock, YAGNI, интеграционные тесты, контрактные тесты, Микроформаты, модульные тесты, пирамида тестов, Тестирование IT-систем, Тестирование веб-сервисов, управление разработкой, юнит-тесты
Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.
«Пирамида тестов» — метафора, которая означает группировку тестов программного обеспечения по разным уровням детализации. Она также даёт представление, сколько тестов должно быть в каждой из этих групп. Несмотря на то, что концепция тестовой пирамиды существует довольно давно, многие команды разработчиков по-прежнему пытаются неправильно реализовать её на практике должным образом. В этой статье рассматривается первоначальная концепция тестовой пирамиды и показано, как её воплотить в жизнь. Она показывает, какие виды тестов следует искать на разных уровнях пирамиды, и даёт практические примеры, как их можно реализовать.
Содержание
- Важность автоматизации (тестов)
- Пирамида тестов
- Какие инструменты и библиотеки мы рассмотрим
- Пример приложения
- Юнит-тесты
- Интеграционные тесты
- Контрактные тесты
- Тесты UI
- Сквозные тесты
- Приёмочные тесты — ваши фичи правильно работают?
- Исследовательское тестирование
- Путаница с терминологией в тестировании
- Внедрение тестов в конвейер развёртывания
- Избегайте дублирования тестов
- Пишите чистый код для тестов
- Заключение
Примечания
JUnit тесты для логирования
2017-12-16 в 18:58, admin, рубрики: java, junit, log4j, mockito, PowerMock, slf4j, тестированиеЛогирование относится к сквозной функциональности — разбросанной по коду и, как правило, редко покрываемой юнит-тестами. Слабое покрытие тестами, очевидно, связано с тем что вывод в лог не всегда достаточно важен и воспринимается скорее как вспомогательная функция а не цель работы метода, к тому же тестировать сквозную функциональность бывает достаточно сложно.
Но когда корректность вывода в лог становится критичной или же чувство прекрасного требует от нас полного покрытия кода тестами — без тестирования логгеров становится не обойтись.
Читать полностью »
7 правил хорошего тона при написании Unit-тестов
2017-09-06 в 7:07, admin, рубрики: java, junit, mockito, Блог компании Wrike, Тестирование IT-систем, тестирование по
“Хорошими манерами обладает тот,
кто наименьшее количество людей
ставит в неловкое положение.”
Дж. Свифт
Привет, коллеги! Сегодня я бы хотел поговорить о Unit-тестировании и некоторых “правилах” при их написании. Конечно, они неформальные и не обязательны к выполнению, но при их соблюдении всем будет приятно и легко читать и поддерживать тесты, которые вы написали. Мы в Wrike видели достаточно Unit-тестов, чтобы понять основные проблемы, которые возникают при их написании и поддержке, и сформулировать несколько правил для их предотвращения.
Читать полностью »
Рефакторинг последовательных проверок в Mockito с помощью fluent-интерфейсов
2016-09-12 в 10:00, admin, рубрики: fluent interface, java, java 8, mockito, юнит-тестированиеУ статических методов есть одна мощная, но и в то же время весьма нежелательная особенность: их можно вызвать из любого места в коде, не особо имея возможность регламентировать порядок их вызова. Зачастую такой контроль очень важен, но иногда порядок не имеет очень большого смысла. Например, осуществлять проверки в юнит-тестах часто можно не в очень строгом порядке. И чтобы гарантировать, что в тестируемом юните выполенены все проверки, в Mockito существует всё тот же статический метод verifyNoMoreInteractions(...). Иногда можно по ошибке вызвать такой метод ещё до последнего verify(...) и потом с огорчением наблюдать "красный" тест. Но что если переложить заботу о порядке выполнения проверок на сам компилятор?
PODAM Java объекты для Unit-тестирования
2015-04-10 в 7:00, admin, рубрики: java, mockito, podam, qa, unit-testing, автоматизация тестирования, Блог компании Кристалл Сервис, Программирование, Тестирование IT-систем, Тестирование веб-сервисов 
Добрый день!
При unit-тестировании часто сталкиваешься с необходимостью заполнять сложные объекты, чтобы возвращать их со стороны заглушек или наоборот — давать их на вход методам и тестам. Некоторые разработчики игнорируют get-set конвенции Java, а даже если геттеры и сеттеры есть, то заполнение объекта достаточно сложной структуры порой требует больше кода, чем сам тест. Это анти-паттерн Excessive Setup, и хочется научиться с ним бороться. В этой статье я расскажу, как с помощью библиотеки PODAM заполнять объекты быстро и красиво, продолжая идеи разумной рандомизации как входных данных для тестов, так и данных, возвращаемых заглушками — покажу на примерах, пороюсь в исходниках.
Итак, чтобы долго не думать, но и не заниматься миром животных, сгенерим страну. Читать полностью »
Шесть простых примеров по Mockito (перевод)
2014-11-13 в 16:21, admin, рубрики: java, mockito, примерыМаленький комментарий:
/*
Решил ознакомиться с тем, что из себя представляет эта библиотека, и отыскал замечательную статью, прочтение которой я хотел бы закрепить, для чего и решил перевести её на русский.
Конечно же, принимается конструктивная критика.
Надеюсь, что комментарии будут полезнее самой статьи, как это обычно и бывает. ;)
*/
Решил ознакомиться с тем, что из себя представляет эта библиотека, и отыскал замечательную статью, прочтение которой я хотел бы закрепить, для чего и решил перевести её на русский.
Конечно же, принимается конструктивная критика.
Надеюсь, что комментарии будут полезнее самой статьи, как это обычно и бывает. ;)
*/
Mockito — прекрасная мок-библиотека для Java. Я очарован тем, как легко её использовать в сравнении с другими подобными библиотеками из мира Java и .NET. В этой статье я привожу всё, что Вам потребуется для старта, в шести очень лёгких примерах.
Читать полностью »
PowerMock(+Mockito) +TestNG и имитация вызова (mock) статических методов
2013-07-07 в 19:32, admin, рубрики: java, maven, mockito, PowerMock, примеры кода, Программирование, тестирование, метки: java, maven, mockito, PowerMock, примеры кода, Программирование, тестированиеНа хабре уже была статья с примерами использования PowerMock, но в ней не хватает такого описания, как имитации вызова статических методов как самостоятельных «единиц» в классе, так и в гибридном использовании, когда часть статических методов у класса подменяются «заглушкой», а часть вызываются реально. Попробую исправить эту нишу.
Для начала создадим демонстрационный класс со статическими методами (commit):
public class ClassStatic {
static String getValue() {
return "value";
}
static String getValue(final String s) {
return getValue() + s;
}
}