TDD *

Важное обновление #1

Storybook используется в качестве хоста для компонентов. Вы можете собирать и хостить компоненты любым другим способом. Например, импортировать их в одном JavaScript-файле и скормить его webpack-dev-server запущенного параллельно с Cypress в течении тетса.

Еще более важное обновление #2

Статья писалась когда версия Cypress была ниже 4.5.
На текущий момент доступны важные обновления Cypress и аддона cypress-react-unit-test. Сейчас не обязательно иметь отдельный хост для компонентов — эту задачу взял на себя Cypress.
Единственная причина реализовать описанный ниже подход — скорость или какие-то баги. Настоятельно рекомендую попробовать аддон cypress-react-unit-test.

Часто самое интересное на митапах начиналось, когда несколько человек увлеченно спорили вокруг какой-то темы, а ты мог включиться с вопросом или добавить свои “пять копеек” опыта.

Мы с Алексеем anzem Землянским и Григорием eyeofhell Петровым подумали перенести эту механику в онлайн. Хотим попробовать 11 апреля в 11 часов по Москве — в формате интерактивной ютуб-трансляции и открытых дискуссий в зуме* за эфиром. Надеемся, у вас найдется полтора часа на протестировать формат с нами.



В качестве темы для первого холивара взяли TDD.

Введение

Давайте представим, что мы разрабатываем небольшое веб-приложение на Laravel версии выше 6 и хотим написать для него тесты.

Содержание статьи приведено ниже:

1. Описание предметной области
2. Создание приложения
3. Создание сущностей
4. Написание тестов
5. Проблема
6. Решение

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

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

В этой статье я постарался:

• осветить «детские болячки» тест-менеджмента, стремящегося автоматизировать все, что не приколочено,
• пояснить, какую пользу может нанести бюджету проекта автоматизация тестирования без детального анализа ее скоупа и должной подготовки,
• составить Roadmap для подготовки к автоматизации проекта.

Источник 

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

В первой части нашего цикла статей мы начали освещать тему эффективности применения методологии TDD для микроконтроллеров (далее – МК) на примере разработки прошивки для STM32. Мы выполнили следующее:

1. Определили цель и инструменты разработки.
2. Настроили IDE и фреймворк для написания тестов.
3. Написали тест-лист для разрабатываемого функционала.
4. Создали первый простой тест и запустили его.

Во второй статье мы описали процесс разработки платформонезависимой логики по методологии TDD.

В заключительной статье мы опишем, как запускали разработанный код на STM32F103C8, а также подведем итоги всего нашего исследования эффективности TDD для микроконтроллеров.

Подробности – под катом.

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

В предыдущей статье мы начали освещать тему эффективности применения методологии TDD для микроконтроллеров (далее – МК) на примере разработки прошивки для STM32. Мы выполнили следующее:

1. Определили цель и инструменты разработки.
2. Настроили IDE и фреймворк для написания тестов.
3. Написали тест-лист для разрабатываемого функционала.
4. Создали первый простой тест и запустили его.

В этой статье расскажем, как мы применили методологию TDD для реализации тестов из тест-листа и написания кода прошивки для их успешного выполнения. При написании тестов будем использовать специальные тестовые объекты для ликвидации зависимостей разрабатываемой логики от других программных модулей. В конце статьи мы представим бизнес-логику проекта и проанализируем особенности применения методологии TDD для реализации прошивки МК. Подробности – под катом.

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

Встраиваемые системы широко применяются в бытовой электронике, промышленной автоматике, транспортной инфраструктуре, телекоммуникациях, медицинском оборудовании, а также в военной, аэрокосмической технике и т. д. Хотя последствия любой ошибки проектирования обходятся дорого, ошибку в ПО для ПК или в большом корпоративном приложении обычно относительно легко исправить. А если дефект будет во встраиваемом ПО (далее – ВПО) электронного блока управления тормозной системой автомобиля, то это может вызвать массовый и дорогостоящий отзыв продукции.

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

Одной из наиболее популярных методологий улучшения качества разрабатываемых приложений является Test-driven development (TDD). Но эффективна ли методология TDD для разработки встраиваемых систем? Ответ на этот вопрос будем искать под катом.

Однажды я разговорился с разработчиком из компании-клиента о программном обеспечении. Мне стоило бы понять то, что разговор пошёл куда-то не туда, когда собеседник сказал о том, как нам, разработчикам ПО, повезло: «Мы обманом заставляем организации платить нам за, как кажется, простую работу». Неважно — насколько некто продвинулся в деле написания кода, но я полагаю, что не стоит говорить обо всей индустрии разработки программного обеспечения как о чём-то вроде шайки мошенников.

Я не стал заострять на этом внимание, разговор добрался до Agile. Клиент, в целом, был открыт идее испытания новых методологий и улучшения своих рабочих процессов. Но — лишь до тех пор, пока я не упомянул о разработке через тестирование (TDD, Test-Driven Development). Единственным ответом на это была следующая фраза: «Значение TDD преувеличено».



Мне не только больно было это слышать, но это заставило меня понять то, что TDD — это ещё одна из тех Agile-методологий, которые могут выглядеть чем-то вроде «городских легенд». Это — то, что заставило меня написать данный материал, в котором мне хотелось бы обратиться к тем, кто сомневается в ценности TDD.

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

Однако бывают и сложные случаи.

В прошлом тексте про ассерты было упущено и недоговорено нечто важное.

В чем состоит различие между given и when и как это связано с ассертами?

Идея, лежащая в основе этого проста — мы хотим ограничить количество ассертов.

Рассмотрим небольшой пример.

Поговорим теперь об ассертах.

Ассерты — одна из само собой разумеющихся вещей, поэтому все тут, казалось бы, специалисты. Кто-то пользуется встроенными в Java или в Junit, кто-то пользуется продвинутыми библиотеками, кто-то сооружает собственную.

Но попробуем подойти к этому более серьезно. Как, на самом деле, правильно?

Проблема синхронизации моков всплывает всякий раз, когда обсуждаются тестовые стратегии. В основном — из-за дополнительной нагрузки, которую моки создают для девелоперов и а также рисков расхождения моков с реальными зависимостями.

Итак, каким способом нам дешевле всего обеспечить синхронизацию моков с реальными имплементациями?

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

Выглядит это как-то так (я пишу без DI, но с DI проще и правильнее):

Среди множество псевдоидей, витающих вокруг ТДД, есть некоторое пренебрежение к test doubles, не в последнюю очередь связанное с их смешными названиями.

Назвали бы их как-нибудь гордо, а то мок, стаб, фейк — ощущение, что мы ничего особо не теряем, если этим не пользуемся. (В противоположность «интеграционным тестам» и «реальным зависимостям»).

Однако можно поменять точку зрения. В конце концов, мок не только и не столько подпирает зависимый компонент, сколько специфицирует поведение зависимости. А «реальная» имплементация — это некое текущее, возможно ошибочное воплощение нашей гордой идеи.

В этом смысле каждый раз, когда мы пишем

when(mockDependency.method(inputValue)).thenReturn(returnValue),

мы документируем некоторое поведение компонента.

Отсюда — несколько следствий.

Рабочие обсуждения TDD и стратегий тестирования часто заходят в тупик.

Фаулер обтекаемо сказал, что это две культуры, мокисты против классиков.

Мокист: Давайте разрабатывать на моках.
— Это пустая трата времени! Их будет некому поддерживать и синхронизировать.
Мокист: Давайте напишем юнит-тесты.
— Полагаться на юнит-тесты опасно!
Мокист: Но если мы правильно разобъем компоненты…
— Да откуда вы уверены, что вы правильно разобъете?
Мокист: Давайте разобъем истории по юзер вэлью.
— Давайте! Но сначала нам нужно пофиксить упавший QA-энвайронмент.
Мокист: Тестировать на моках быстрее.
— Только интеграционные тесты на реальных зависимостях дадут нам ценную информацию! Да и кто ваши юнит-тесты будет поддерживать.
Мокист: Но интеграционные тесты долго выполняются и покрывают меньше сценариев.
— У меня на огромном проекте в прошлом все было прекрасно!

— Наши интеграционные тесты сломаны уже две недели. — Поставь skipTests и пропихни в QA, у нас деплоймент горит.
— Вы же обещали, что после релиза мы сможем отрефакторить лишние зависимости. — У нас продакшен инцидент, займись реальной работой.

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

Можно предложить другой вариант: ботаники против реальных пацанов.

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

В этом есть резон, но так ли уж неполны юнит-тесты и можно ли сделать их надежнее? Сколько вообще причин их неполноты?

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

Однако они очень важны.

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

Каким образом мы могли бы сделать наши утверждения лучше?

Содержание цикла статей: https://github.com/nomhoi/empire-erp.

В данной статье мы осуществим попытку проникновения в самое сердце "кровавого энтерпрайза" — в бухгалтерию. Вначале мы проведем исследование главной книги, счетов и баланса, выявим присущие им свойства и алгоритмы. Используем Python и технологию Test Driven Development. Здесь мы займемся прототипированием, поэтому вместо базы данных будем использовать базовые контейнеры: списки, словари и кортежи. Проект разрабатывается в соответствии с требованиями к проекту Empire ERP.

Заметил. что работа с любым заказчиком очень похожа на работу веб-приложения. В статье показано как можно воспользоваться этим знанием для улучшения процессов.

О том кто же является контроллером, а кто моделью под катом.

Около 3 лет назад я перешел с C# разработки на Python. Два с половиной года я пытался найти инструмент, который был бы похож на NCrunch по удобству в ежедневной работе.

В какой-то момент я забил на unit-тестирование, и писал код, прогоняя тесты на CI.

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

Полгода разработки, и активное использование на собственных проектах, вызывает желание показать продукт сообществу.

«А зачем мне это нужно?»:

1. Автоматический запуск только тех тестов, которые затронуты изменениями кода. (Запуск происходит в фоновом режиме, и не отвлекает от написания кода)

2. Понимание, какие конкретно тесты, затрагивают определенную строчку кода (Удобно, например, отслеживать путь выполнения программы и понимать какие ветви кода еще не покрыты тестами):

Page Objects могут быть использованы как мощный метод абстракции (изоляции) ваших тестов от технической реализации. Важно помнить, их (Page Objects) можно использовать для увеличения стабильности тестов и поддержания принципа DRY (do not repeat yourself) — посредством инкапсуляции функционала (вебсайта) в простых методах.