В настоящий момент занимаюсь реализацией взаимодействия с поставщиком KYC услуг. Как обычно ничего космического. Нужно просто выбрать из своей базы данных некий достаточно объемный комплект экземпляров различных записей, выгрузить их поставщику услуг и попросить поставщика записи эти проверить.

Начальная стадия обработки содержит десяток идентичных операций с отправкой запросов на извлечение данных некоего конкретного пользователя из различных таблиц базы. Есть предположение что при этом достаточно большую часть кода можно будет использовать повторно в виде абстракции Request. Попробую предположить как этим можно было бы пользоваться. Напишу первый тест:

Spock предоставляет 3 мощных (но разных по сути) инструмента, упрощающих написание тестов: Mock, Stub и Spy.

Довольно часто коду, который нужно протестировать, требуется взаимодействовать с внешними модулями, называющимися зависимостями (в оригинальной статье используется термин collaborators, который не очень распространён в русскоязычной среде).

Модульные тесты чаще всего разрабатываются для тестирования одного изолированного класса при помощи различных вариантов моков: Mock, Stub и Spy. Так тесты будут надёжнее и будут реже ломаться по мере того, как код зависимостей эволюционирует.

Такие изолированные тесты менее подвержены проблемам при изменении внутренних деталей реализации зависимостей.

От переводчика: каждый раз, когда я использую Spock Framework для написания тестов, я чувствую, что могу ошибиться при выборе способа подмены зависимостей. В этой статье есть максимально краткая шпаргалка по выбору механизма для создания моков.

Вторая статья из цикла "Test-Driven Development приложений на Spring Boot" и в этот раз я буду говорить про тестирование доступа к базе данных, важного аспекта интеграционного тестирования. Я расскажу как через тесты определять интерфейс будущего сервиса для доступа к данным, как использовать встраиваемые in-memory базы для тестирования, работать с транзакциями и загружать тестовые данные в базу.

Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.

Из моего личного опыта внедрения методов надежного программирования в своей компании, в компаниях, которые я консультировал, общения на конференциях, а также из публично доступных источников, я сформулировал типичные возражения и сопротивления, которые препятствуют внедрению культуры автоматического тестирования.

Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня:

Аннотация

Статья рассказывает о нетрадиционном, но полезном виде тестов, а также подводит итоги семилетней работы в разработке тестов.

Зачем нужны компонентные тесты?

Ведь есть, скажем, юнит-тесты, которые подробно тестируют потроха компонентов. Они досконально проверяют, что компонент работает в соответствии с замыслом разработчика. Но часто это проверка "пуговиц", а не того, как сидит костюм в целом. И не всегда поведение, задуманное программистом, совпадает с тем что хотел заказчик.

А еще есть, например, приемочные тесты. И они устраняют все указанные недостатки. Но, к сожалению, вносят новые. Они медленные, часто нестабильные, и обычно ручные. При этом они только свидетельствуют о проблеме, но не локализуют ее.

Очевидно, что напрашивается необходимость промежуточных тестов, которые станут золотой серединой между тестами модульными и приемочными. Этой серединой могут стать компонентные тесты.

Введение

Терминология

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.

Содержание

• Вступление
• Тесты и есть проблема!
  
  • Немного истории
  • Небольшая викторина
• Обзор TDD
  
  • Тесты — это формализованные требования
  • TDD поощряет хорошую архитектуру
  • TDD экономит время
  • Тесты — это лучшая документация
  • Немного выводов
• В чём же решение?
  
  • Несколько примеров
  • Немного про планы

Привет, Хабр! Представляю вашему вниманию перевод статьи Test Contra-variance

От переводчика: честно говоря, выбор слов ко-/контравариантность, по отношению к дизайну тестов, немного странен. Семантика конечно прослеживается, но весьма метафорична. Скорее всего, просто для красного словца и заголовка, привлекающего внимание, поэтому не сильно придирайтесь. В остальном — прекрасная заметка на тему TDD в формате диалога. Рассказано почему TDD это так больно, как сделать из юнит-тестов приятный инструмент и не относится к ним как к обязательно ломающемуся насилию над свободой самовыражения.

Привет, Хабр! Какое-то время назад я заинтересовался фреймворком Hanami и, чтоб лучше отложилось в голове, начал переводить официальное руководство для новичков. Этим и хочу поделиться с сообществом. Переводить я старался ближе к оригиналу, но я более читатель, чем писатель и, если у вас будут замечания к переводу, не стесняйтесь их высказывать, я поправлю.

В этом руководстве мы создадим свой первый проект в Hanami, сделаем простое веб приложение. Мы коснемся всех основных компонентов фреймворка и покроем все написанное тестами.

— Слава TDD!
— Юнит-тестам слава!

В этой статье мы разберемся с принципами применения MVP+TDD в разработке iOS приложений. Разбираться будем на примере создания небольшой обучалки для пользователя, которая показывается при первом запуске.

Требования от бизнеса

Итак, ваш заказчик хочет, чтоб в его приложение добавили обучалку, которая покажется пользователю один раз при первом запуске. Обучалка состоит из нескольких изображений, которые должны быть показаны в определенной последовательности. Переключаться изображения должны по нажатию на кнопку "Продолжить". Также при показе последнего изображения — на кнопке нужно написать "Старт" (как бы намекая пользователю, что приложение будет сейчас запущено).