TDD *

Я часто собеседую кандидатов на позиции .Net разработчиков в Retail Rocket. В прошлом работал в компаниях с различными командами. И далеко не один раз встречал и продолжаю встречать мнение, что “автотесты хорошо, но на них нет времени, писать их дорого, тестировать должны тестировщики”. Такое мнение не у всех, но встречается нередко (не исключаю, что мне так «везет»). В связи с этим хочу поделиться нашим подходом к автоматическому тестированию и обеспечению качества. Расскажу путь, который мы в Retail Rocket прошли за последние 3-4 года, к чему пришли сейчас, и —  главное — что дают нам автотесты и для чего мы их пишем. Надеюсь, статья кого-нибудь сподвигнет писать автотесты, кого-то — писать больше автотестов, а кому-то, возможно, поможет избежать ошибок, с которыми мы сталкивались.

Если Вы разрабатываете более-менее сложный программный продукт, то Вам должна быть знакома ситуация, когда системные (end-to-end) тесты по тем или иным причинам автоматизировать не удаётся. На это могут быть разные причины, я приведу несколько примеров:

• У приложения нет и не может быть API, за которое можно зацепиться, по соображениям безопасности;
• Приходится поддерживать legacy-проект, про автоматизацию тестирования которого никто никогда не задумывался;
• Во время тестирования задействуется сторонний продукт, например — антивирус;
• Необходимо проверить работоспособность продукта на большом количестве различных целевых платформ;
• Тестовый стенд представляет собой сложную гетерогенную систему, включающую в себя промежуточное сетевое оборудование.

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

Если Вы ищете решение этой проблемы — то прошу под кат.

Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём разные темы из компьютерной науки и деконструируем их по полочкам. Начнём мы с разработки через тестирование.

Test Driven Development

Суть этого подхода заключается в ритуализации процесса разработки. То есть в некритическом безусловном выполнении определённых простых действий.

Этот ритуал сделает ваш код красивым и надёжным. Поддерживать его будет легко и просто. А разработка будет простой и быстрой. Так во всяком случае настоятельно убеждают нас проповедники TDD.

Видео запись этого разбора.

Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?

Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".

Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.

Наверняка все слышали что про модели, MVC, AR и другие замечательные слова.

Но все ли до конца понимают, что эти слова означают?
Все ли понимают что такое модель и как она должна выглядеть

Давайте порассуждаем (и не только) на эту тему.

И вынести тестируемые результаты вне кода. Это статья об автоматизации и увеличения удобства тестирования на Python.

Вводная

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

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

Результаты выполнения можно проверять в python коде тестов. Это близко к контексту выполнения и зачастую удобно.

Но это также может быть неудобно когда:

Есть полно исследований, демонстрирующих эффективность 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.

Введение

Давайте представим, что мы разрабатываем небольшое веб-приложение на 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 для разработки встраиваемых систем? Ответ на этот вопрос будем искать под катом.