Читаю тут обсуждение вот к этому посту:
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.
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.
Комментариев нет:
Отправить комментарий