среда, 18 июня 2014 г.

Ещё немного про TDD

Читаю тут обсуждение вот к этому посту:

http://habrahabr.ru/post/116514/

Например вот:

"Тесты это здорово, но не всегда удается их нависать. 
В книгах по ТДД зачастую описываются сферический код в ваукуме типа приема заказов или справочника сотрудников. Не спорю писать тесты под это легко и просто но к суровой реальности это относится не часто. Особенно если для выполнения тестов нужно воссоздать сложное окружение из кучи сторонних компонентов. Тут я просветления не достиг и тестирую только части, не нуждающиеся в сложном окружении. Это кстати влияет и на сам код — приходится некоторые методы разделять чтобы написать тест под них. 

И, имхо, TDD (именно тдд а не юнит тесты) не всегда возможно. Есть класс задач где тесты не могут быть инициатором разработки и дизайна. Все равно в начале нужно продумать архитектуру а потом наращивать мясо. 

Вопросы к ТДД гурам:
1. Что вы делаете с тестами если поменялась архитектура? Удаляете, переписываете? Вариант ответа: «ТДД дает сразу правильную архитектуру» не канает. 
2. Как тестировать сложное окружение? Тестировать только элементарные блоки? или писать кучу моков?"

И создаётся впечатление, что либо люди РЕАЛЬНО не понимают, либо ими "движет банальная лень".

Мол зачем писать тесты? Это мол "напрасная трата времени".

Только есть ОДНА ВЕЩЬ - которую я ВСЁ ПЫТАЮСЬ донести - "тесты это не средство поиска ошибок" (http://habrahabr.ru/post/149903/).

Тесты это средство ПРОВЕРЯТЬ ДЕТЕРМИНИРОВАННОСТЬ кода.

Тесты это - ИНФРАСТРУКТУРА. Которая "ведёт за собой разработку". Именно ПОЭТОМУ в TDD присутствует слово Driven.

Можно начать разработку с теста, а закончить "привязыванием функционала к GUI", а не наоборот. Я писал тут - http://programmingmindstream.blogspot.ru/2014/06/blog-post_16.html

А если слова "привязывание к GUI" заменить на слова "ожидание смежников", то по-моему становится несколько понятно, что "это не просто трата времени", а ещё и ИНФРАСТРУКТУРА. Помогающая разработке.

Но!

КРОМЕ ЭТОГО - есть ещё одна вещь - когда тесты "набирают мясо", то случается такой момент, что "тестовый функционал" оказывается настолько МОЩНЫМ, что он начинает "плавно перетекать" из тестов в "бизнес-логику". И ТАКИМ ОБРАЗОМ он начинает "подстёгивать" процесс разработки.

И код написанный "для тестов" становится ПОЛНОЦЕННЫМ кодом бизнес-логики.

Как?

Про это я думаю в скором времени написать. В нашей серии "Тестирование калькулятора".

Текущее оглавление серии тут - http://programmingmindstream.blogspot.ru/2014/06/blog-post_10.html.

Комментариев нет:

Отправить комментарий