Все потоки

TDD *

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

СтатьиПостыНовостиАвторыКомпании

@rudnevr 1 ноя 2019 в 08:02

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

2 мин

3.2K

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

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

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

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

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

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

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

-13

@rudnevr 29 окт 2019 в 23:30

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

2 мин

5.1K

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

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

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

0

@rudnevr 27 окт 2019 в 21:02

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

3 мин

4.7K

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

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

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

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

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

+2

@nomhoi 13 окт 2019 в 10:53

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

8 мин

6.9K

ERP-системы * Python * TDD * Анализ и проектирование систем *

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

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

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

+9

@aak74 6 окт 2019 в 16:27

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

6 мин

7.2K

IT-компанииTDD * Тестирование IT-систем * Управление проектами * Управление разработкой *

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

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

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

+6

@Gleb_Sevruk 17 сен 2019 в 06:18

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

1 мин

3.5K

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

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

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

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

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

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

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

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

+8

@hihilisk 6 сен 2019 в 15:08

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

6 мин

6K

TDD * Тестирование веб-сервисов *

Из песочницы

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

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

+7

@MarsiBarsi 29 июл 2019 в 12:35

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

2 мин

13K

Блог компании Т-БанкJavaScript * TDD * Тестирование веб-сервисов *

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

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

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

+21

@Pavel_Yurkin 4 июл 2019 в 07:41

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

27 мин

20K

Блог компании Лемана ТехТестирование веб-сервисов * История ITTDD * Java *

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

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

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

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

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

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

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

+27

@Karl_Marx 25 июн 2019 в 16:52

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

14 мин

18K

TDD * Управление проектами * Финансы в IT

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

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

+9

@Sergamers 13 июн 2019 в 21:27

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

3 мин

7.1K

Тестирование веб-сервисов * Программирование * TDD * JavaScript *

Из песочницы

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

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

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

+8

@dartmessiah 6 июн 2019 в 11:42

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

7 мин

15K

Блог компании PixonicTDD * Разработка игр * Тестирование игр *

Перевод

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

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

+42

@HomoLuden 5 июн 2019 в 08:22

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

5 мин

2.3K

Туториал

Перевод

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

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

+9

@wizi4d 14 мая 2019 в 04:04

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

14 мин

11K

JavaScript * Node.JS * TDD * Дизайн игр * Разработка игр *

Введение

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

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

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

+3

@ru_vds 2 мая 2019 в 10:15

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

10 мин

158K

Блог компании RUVDS.comTDD * Веб-разработка *

Перевод

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

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

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

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

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

+33

@OlegusTesterovichus 2 мая 2019 в 03:23

GitLab Shell Runner. Конкурентный запуск тестируемых сервисов при помощи Docker Compose

12 мин

33K

Тестирование веб-сервисов * Тестирование IT-систем * Микросервисы * TDD * DevOps *

Данная статья будет интересна как тестировщикам, так и разработчикам, но рассчитана в большей степени на автоматизаторов, которые столкнулись с проблемой настройки GitLab CI/CD для проведения интеграционного тестирования в условиях недостаточности инфраструктурных ресурсов и/или отсутствия платформы оркестрации контейнеров. Я расскажу, как настроить развертывание тестируемых окружений при помощи docker compose на одном единственном GitLab shell раннере и так, чтобы при развертывании нескольких окружений запускаемые сервисы друг другу не мешали.

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

+12

@fatescreen 22 фев 2019 в 08:16

Ceedling + Eclipse или unit-тесты для микроконтроллеров

2 мин

11K

Тестирование IT-систем * Производство и разработка электроники * Программирование микроконтроллеров * TDD * Eclipse *

Из песочницы

Программируешь микроконтроллеры? Начитался про TDD или просто устал искать баги и переписывать код заново?

Друг, попробуй тесты.

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

+12

@Quality_lab 15 фев 2019 в 17:20

Цена качества: 7 принципов оптимизации затрат на тестирование

10 мин

18K

TDD * Тестирование IT-систем * Управление продуктом * Управление проектами * Управление разработкой *

Из песочницы

image alt

Думаете, как сэкономить на тестировании вашего ПО? Вы не одиноки. Возникает лишь одно маленькое но: если софт не дотестировать, возможны самые негативные сценарии – от дорогостоящей и крайне невыгодной вам доработки приложения на поздних стадиях до потери репутации и ухода клиентов/заказчиков к конкурентам.

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

+26

@dopefish_hunters 29 янв 2019 в 05:00

Как мы автоматизировали запуск Selenium-тестов через Moon и OpenShift

8 мин

23K

Блог компании СберOpenshift * TDD * Тестирование IT-систем * Тестирование веб-сервисов *

14 декабря на митапе в Санкт-Петербурге я (Артем Соковец) совместно с коллегой, Дмитрием Маркеловым, рассказывал о текущей инфраструктуре для автотестов в СберТехе. Пересказ нашего выступления — в этом посте.

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

+16

@mvist222 19 янв 2019 в 14:28

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

4 мин

8.9K

Laravel * PHP * TDD * Тестирование IT-систем *

Из песочницы

В жизни каждого разработчика наступает момент, когда он задумывается над созданием тестовой составляющей для своего детища. Поправлюсь — в жизни каждого хорошего разработчика. Когда ты джуниор и не несешь особой ответственности, имеешь право на уйму ошибок и можешь их исправить в любой момент. Ты не отвечаешь за тот продукт, что создаешь и не имеешь мотивации тратить лишнюю минуту на перепроверку созданного кода. «Да ничего, этот косяк не воспроизведется», «кажется, эта штука работает», «ну как минимум, она делает то что нужно» — если вы желаете перерасти уровень программерских яслей, то придётся свести на нет каждую из этих мыслей.

С развитием собственного опыта программирования, у вас появляются новые всё более и более крутые/крупные клиенты. От некоторых вы даже будете в восторге (от всех, если вы прям везунчик) — и люди хорошие, и оплачивают щедро, и не придирчивы к возникающим проблемам. Давайте рассмотрим один такой простой случай (очень простой, но главное то, что за этим стоит) создания обработчика формы от программиста, не знающего хлопот.

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

+13

6

7 8 ...