TDD шагает по планете

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

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

Ключевые цифры здесь —

  • Пишем тесты от случая к случаю (24.63%)
  • Не используем автоматизированные тесты в разработке (50.27%)

Итого, даже с учетом того, что на хабре присутствует скорее продвинутая часть ИТ-сообщества, в 75% компаний культуры автоматизированного тестирования просто нет. Собственно, говорить о множестве позитивных примеров ТДД уже становится сложно, потому что становится ясно — тесты в принципе используются только в «наиболее продвинутых» компаниях, и легко предположить, что и отношение к качеству продукта, и уровень специалистов в таких компаниях выше.
К слову, «признались» в использовании ТДД только 4% разработчиков.

Любопытным итогом дискуссии, развернувшейся в комментариях, для меня стало подтверждение гипотезы об относительной нежизнеспособности «классического ТДД» — подхода, при котором строго перед написанием кода пишутся тесты на него, и строго весь код пишется именно таким подходом.
Подтверждением стало довольно частое упоминание BDD (пропагандирующей, по сути, средне-интеграционные тесты на поведение подсистем), и ряд споров о трактовке понятия «юнит» в термине «юнит-тест», часто под юнитом люди подразумевают некую подсистему, а не отдельный класс/метод.

Опрос в целом получился весьма любопытным и с несколько неожиданными для меня результатами (я ожидал порядка 30-40% за два последних пункта, но никак не 75). Любопытно будет повторить через годик-два.

Опубликовать в Facebook
Опубликовать в Google Plus

5 комментариев

  1. Но BDD же все-таки TDD+acceptance-тесты+особый нейминг. Кстати, именно acceptance-тесты, а не среднеинтеграционные. Так что, Артур, попытка подогнать BDD под поход, которому ты симпатизируешь, не засчитана :)

  2. Щас снова дискуссию развернем :) Нет, BDD — это не acceptance тесты. Acceptance-тесты это через GUI. BDD — это не через GUI.

    И из того, что писали товарищи с хабра, практикующие BDD, как раз и следует, что они не позиционируют «классическое ТДД» как часть их БДД-подхода.

    Да, между БДД и средне-интеграционными есть разница, но тут опять тонкости терминологии. Подмножество «средне-интеграционные тесты» включает в себя подмножество «БДД». Но и не только их, да.

  3. Acceptance-тесты — это acceptance-тесты. Они могут идти как через GUI, так и не через GUI. Элементарно у некоторых библиотек и приложений нет GUI.

    Не думаю, что стоит ориентироваться на товарищей, писавших что-то в комментариях на Хабре. Я погуглил «BDD vs. TDD» и пришел к выводу, что BDD именно дополняет TDD. Вдобавок создал такой вопрос на programmers: http://programmers.stackexchange.com/questions/111837/relation-between-bdd-and-tdd

    Насколько я могу судить, BDD-тесты максимально интеграционные — иначе бы их не называли acceptance-тестами.

  4. > Не думаю, что стоит ориентироваться на товарищей, писавших что-то в комментариях на Хабре.

    Пост-то как раз о ситуации в индустрии :) Поэтому да, я и ориентируюсь на то, что говорят на хабре.

    Сейчас я не говорю, как правильно делать БДД или ТДД. Я исключительно говорю о том, что практикуют люди. То, что в комментах называлось БДД — не было «дополнением чистого ТДД», и не обязательно было acceptance.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *