Исследование подходов к разработке

Сравнение обычных подходов и TDD

​

Зачем исследовать?

1. Не нашёл точных исследований
2. Раз и навсегда развеять мифы о TDD научным подходом
3. Собрать факты о разных подходах к разработке
4. Выбрать самый лучший
5. Писать код максимально эффективным способом
6. Подтолкнуть остальных к использованию этого идеального способа разработки

Цели исследования

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

Каждый исследуемый подход должен совпадать по качеству с другими.

Термины

Unit тест - проверяет отдельный модуль в изоляции от других

Интерграционный тест - проверяет приложение в связке с другими

Регрессионный тест - проверяет факт работы всех выполненных задач

​

Исследуемые подходы

2. TDD с двумя способами тестирования результата:
1. регрессионное тестирование со стороны QA
2. интеграционное тестирование со стороны QA

• Классический подход к написанию кода c двумя способами тестирования результата:
• регрессионное локальное тестирование + интеграционное тестирование со стороны QA
• регрессионное тестирование со стороны QA

Как сравнить?

Математически

Написать формулы для моделирования разных подходов

Рассчитать по формулам затраты на разработку

Сравнить и сделать выводы

Экспериментально

Выполнить ряд сторисов-задач на сервисном методе

Замерить время всех этапов работы

Сравнить и сделать выводы

Экспериментально

Сделал простенькую программу для расчёта скидки и 7 сторисов по её доработке

Репозиторий

Для большей сложности последние 3 сториса содержат взаимосвязь со внешним сервисом

Запрограммировал все 7 сторисов тремя подходами: 2 подхода TDD и один классический

Ссылка на видео

Результат:

1. TDD 2: 3м 11с
2. Классический: 3м 53с
3. TDD 1: 4м 22с

Математически

Построил формулы для расчёта стоимости разработки всех 4-ех подходов

Перенёс формулы в google calc и подставил данные, полученные в ходе экспериментов

Ссылка на формулы

Построил графики по ним

Ссылка на таблицу

Результаты оптимистичного расчёта затрат

Среднее время на тестирование одной фичи через запуск приложения в консоли 16.4 секунды (переменная Тест)

Это время самого быстрого способа ручного тестирования - через консоль

Долгосрочные затраты

На 23-ей задаче TDD выгоднее в 1.6 раза

Результаты реалистичного расчёта затрат

Среднее время на тестирование одной фичи через запуск приложения в Jaeger 30 секунд

Ещё не учитывается время на возню со состоянием в сторонних сервисах

На 21-ой задаче TDD выходнее в 2.1 раза

Выводы

1. TDD становится эффективным только после реалиазации X кейсов\сторисов в одном и том же методе
2. X напрямую зависит от
1. TDD навыков разработчика
2. От скорости интеграционного тестирования при классическом методе разработки того же функционала.
3. От применения других способов автоматизации тестирования (в том числе QA)
3. Для меня этот X равен
• 10 сторисам, при условии что интеграционное тестирование присходит через консоль
• 6 сторисам, при условии, что тестируется через Jaeger

Какие методы покрывать

1. Как вариант, те методы, которые были изменены построчно по истории git >= X раз
2. Например, при исследовании одного метода на проде на глубину 1, он был задет в 14 задачах.
3. Скорее всего ситуация хуже, поскольку это только глубина 1 и 1 задача больше 1 сториса

Дополнительные плюшки TDD

• Чистый код. Вы пишете только тот код, который необходим.
• Простой код. Сложный код тяжело тестировать, поэтому появляется мотивация писать простой код
• Легко рефакторить. Покрытый код можно без последствий смело рефакторить
• Тесты документируют код. Не нужно писать комментарии. Достаточно посмотреть на тесты, которые показывают кейсы, при которых используется метод
• Меньше отладки. Отладчик с тестами в большинстве случаев не нужен. Если возникла необходимость отладить и поймать баг, значит нужно ещё один тест.

Всем спасибо!

Репозиторий эксперимента с другими ссылками:

https://github.com/execut/work-way-experiments/blob/master/README.md