Как стать автором
Обновить
1.2

TDD *

Разработка через тестирование

Сначала показывать
Порог рейтинга
Уровень сложности

Мой ответ тем, кто полагает, что значение TDD преувеличено

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

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



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

Given, when, ассерты и доверие к имплементации

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

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

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

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

Как правильно писать ассерты

Время на прочтение2 мин
Количество просмотров5.9K
Поговорим теперь об ассертах.

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

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

Синхронизация моков с реальными имплементациями

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

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

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

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

Мок — это не костыль, мок — это спецификация

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

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

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

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

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

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

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

TDD, мокисты и реальные пацаны

Время на прочтение2 мин
Количество просмотров3.1K
Рабочие обсуждения TDD и стратегий тестирования часто заходят в тупик.

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

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

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

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

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

Два способа сделать надежные юнит-тесты

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

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

TDD: как правильно писать спецификации (describes)

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

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

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

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

Empire ERP. Занимательная бухгалтерия: главная книга, счета, баланс

Время на прочтение8 мин
Количество просмотров6.6K

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


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

Читать дальше →

Программист, менеджер, MVC и критерии приемки

Время на прочтение6 мин
Количество просмотров6.9K

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


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

Читать дальше →

PyCrunch – Интеллектуальное выполнение тестов и визуальное покрытие кода в IDE

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

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

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

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

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

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

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


Читать дальше →

Тестирование пользовательского функционала вебсайта с помощью Capybara page objects

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

Собираем окружение для современного TDD на JavaScript + VS code

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

image

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

Ближайшие события

Как сэкономить на психотерапевте используя test-driven development

Время на прочтение27 мин
Количество просмотров20K
У вас когда-нибудь было такое состояние?

image

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

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

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

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

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

Сколько стоят юнит тесты?

Время на прочтение14 мин
Количество просмотров18K
image

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

Читать дальше →

Настройка окружения unit тестирования javascript

Время на прочтение3 мин
Количество просмотров6.9K

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


image


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

Читать дальше →

TDD в геймдеве или «кроличий ад»

Время на прочтение7 мин
Количество просмотров15K
TDD в геймдеве применяют довольно редко. Обычно проще нанять тестировщика, чем выделить разработчика для написания тестов — так экономятся и ресурсы, и время. Поэтому каждый успешный пример использования TDD становится интереснее. Под катом перевод материала, где эту технику разработки применили при создании передвижения персонажей в игре ElemenTerra.


Читать дальше →

Об удобочитаемом именовании тестов в JS и поведенческом паттерне

Время на прочтение5 мин
Количество просмотров2K

В ходе очередного ревью толстого Pull Request'а наткнулся на Unit Test'ы с некорректным именованием тест-кейсов. Обсуждение формулировок в тест-кейсах получилось похожим на разговор Янычара и Легкоступова в к/ф "72 метра" ("если б мне в школе так доходчиво..."). В разговоре прозвучала мысль, что в рускоязычных ресурсах трудно найти толковый гайд именно по текстовым формулировкам. Решил искать самолично на русском (обычно я пользуюсь только англоязычными источниками). На хабре нашел несколько мануалов про юнит-тесты, но все они обходят стороной детали формулировок в тест-кейсах. Под катом моя попытка восполнить данный пробел.

Читать дальше →

Завариваем геймдев. Часть 1

Время на прочтение14 мин
Количество просмотров10K

Введение


История началась с хакатона по разработке игр на блокчейне. На старте мероприятия я встретил человека, который в качестве хобби создает настольные деловые игры (я был на плейтесте одной такой игры), мы объединились, вместе нашли команду, с которой за выходные “слепили” простую стратегическую игру. Хакатон прошел, а задор остался. И у нас родилась идея многопользовательской карточной игры о счастье, мировом сообществе и выборах.

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

  • Краткая информация об игре
  • Как принималось решение на чем делать backend. Где это будет “жить” так, чтобы за это не платить на этапе разработки
  • Первые шаги в разработке — аутентификация игроков и организация поиска игры (matchmaking)
  • Дальнейшие планы
Поехали

TDD: методология разработки, которая изменила мою жизнь

Время на прочтение10 мин
Количество просмотров134K
На часах 7:15 утра. Наша техподдержка завалена работой. О нас только что рассказали в передаче «Good Morning America» и множество тех, кто впервые посещает наш сайт, столкнулось с ошибками.

У нас настоящий аврал. Мы, прямо сейчас, до того, как потеряем возможность превратить посетителей ресурса в новых пользователей, собираемся выкатить пакет исправлений. Один из разработчиков кое-что подготовил. Он думает, что это поможет справиться с проблемой. Мы размещаем ссылку на обновлённую версию программы, пока ещё не ушедшей в продакшн, в чат компании, и просим всех её протестировать. Работает!

Наши героические инженеры запускают скрипты для развёртывания систем и через считанные минуты обновление уходит в бой. Внезапно число звонков в техподдержку удваивается. Наше срочное исправление что-то поломало, разработчики хватаются за git blame, а инженеры в это время откатывают систему к предыдущему состоянию.

image

Автор материала, перевод которого мы сегодня публикуем, полагает, что всего этого можно было бы избежать благодаря TDD.
Читать дальше →