TDD *

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) — посредством инкапсуляции функционала (вебсайта) в простых методах.

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


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

У вас когда-нибудь было такое состояние?


Хочу показать вам, как TDD может улучшить качество кода на конкретном примере.
Потому что всё то, что я встречал при изучении вопроса, было довольно-таки теоретическим.
Так получилось, что мне довелось написать два практически идентичных приложения: одно писалось в классическом стиле, так как я ещё не знал тогда TDD, в второе — как раз с использованием TDD.

Ниже я покажу, где были самые большие различия.

Лично мне это было важно, потому что каждый раз, когда кто-то находил баг в моём коде, я ловил увесистый минус на самооценку. Да, я понимал, что баги — это нормально, их пишут все, но ощущение неполноценности никуда не уходило. Также, в процессе эволюции сервиса, я иногда понимал, что сам понаписал такого, что чешутся руки всё выкинуть и переписать заново. И как это получилось — непонятно. Как-то всё было хорошо в начале, но вот пару фич и через некоторое время уже на архитектуру без слёз не взглянешь. Хотя вроде каждый шаг изменения был логичный. Ощущение того, что мне не нравится продукт собственного труда, плавно перетекало в ощущение, что программист из меня, простите, как из говна пуля.

Оказалось, я не один такой и схожие ощущения возникают у многих моих коллег. И тогда я решил, что либо научусь писать нормально, либо пора менять профессию. Я попробовал test-driven development в попытке что-то изменить в своём подходе к программированию.

Забегая вперёд, по результату нескольких проектов, могу сказать, что TDD даёт более чистую архитектуру, но при этом замедляет разработку. И подходит не всегда и не всем.

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

Вначале была функция и вызывали ее в одном месте. Потом мы захотели вызвать ее в другом месте с новыми возможностями и обновили ее. Нам эта ф-ия так понравилась, что мы вызвали ее в третьем месте и еще сделали функциональные правки и… в первом месте что-то пошло не так. А как узнать? Проверять во всех местах где мы использовали эту функцию, все ли правильно работает? Можно, но лучше использовать unit тесты.

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