TDD *

Во время интересной дискуссии, один очень уважаемый человек «козырнул» «неубиваемым» аргументом:

Есть полно исследований, демонстрирующих эффективность TDD

Действительно. Если зайти на Google Scholar, забить ключевые слова «TDD» и «Эффективность» — будет много научных статей, но так ли все просто? Хоть я сам и являюсь большим фанатом TDD, но я так же считаю себя скептиком, и решил проверить, доказано ли научно, что TDD так крут.

Мы, разработчики, очень любим юнит-тесты, полезность которых очевидна. И чтобы эти тесты действительно были полезными, а не приносили боль, необходимо обеспечивать их стабильность.

Наша компания разрабатывает интерфейсный фреймворк "Wasaby" и продает построенные на его базе продукты, представляющие собой облачные и десктопные приложения. Релизный цикл у нас жестко привязан к календарю, а для контроля качества продукта настроены процессы непрерывной инеграции. Мы используем Jenkins для сборок и Mocha в связке с Chai assert для юнит тестирования JavaScript кода. И недавно мы столкнулись с ситуацией, когда мониторинг сборок стал показывать, что примерно половина всех случаев их падения приходится на нестабильные юнит-тесты JavaScript. Симптоматика при этом одинаковая: отдельный тест из набора либо не успевает выполниться, либо возвращает не тот результат, что ожидается. И анализ кейсов практически всегда выявляет факт, что падает тест, содержащий вызовы функций setTimeout или setInterval в собственном, либо в тестируемом коде. О том, как правильно поступить в этой ситуации, мы и будем говорить дальше.

Всем привет!

Меня зовут Антон и сейчас (не так долго, около года) я разрабатываю на PHP в одном большом и старом проекте. Для обеспечения качества проекта мы применяем автотесты на фреймворке PHPUnit. Но, к сожалению, так получилось, что большая часть наших автотестов функциональные. Недавно мы поняли, что если мы продолжим использовать автотесты прежним образом, то скоро время, потраченное на решение проблем с их не прохождением на CI станет больше, чем время, затраченное на написание полезного кода (на самом деле нет, но оно растёт и это не приятно).

Для системного решения этой проблемы мы выбрали подход, который предполагает написание множества unit-тестов и минимального количества фунциональных тестов. Так же мы решили, что в рамках изменений существующего кода необходимого по правилу бойскаута актуализировать существующие тесты. Некоторое время — все это время мы пилили новые фичи — у нас все было прекрасно. Но недавно мне прилетела задача исправить багу в старом коде. Я начал писать unit-тесты, и понял, что проснулось древнее зло легаси. Стало понятно, что это путь в никуда:

• я писал пару тест-кейсов несколько часов;
• понял, что за это время написал очень, очень много повторяющегося кода;
• фактически не сделал полезной работы;
• в случае изменения DI придется потратить очень много времени на бесполезную адаптацию кода теста.

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

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

Под катом вы узнаете как получить:

• Запуск тестов из TFS
• Автоматический линк сценариев к тесткейсам в TFS
• Всегда актуальное содержание тесткейсов в TFS
• Возможность редактировать сценарии прямо в системе контроля версий тестировщиками
  

Важное обновление #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, поскольку тут мало программирования.

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

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

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