воскресенье, января 08, 2006

И снова о модульном тестировании

Наткнулся на интересную статейку написанную Mike Spille с критикой модульного тестирования (Unit Testing). Статья ставит своей целью разоблачение мифа об эффективности модульного тестирования и ведет критику в двух основных направлениях:

1. Модульное тестирование представляет наименее важный и малозначительный элемент тестирования программного продукта. Настолько малый и незначительный, что придавать ему сколько-нибудь важности и высокого смысла - ошибка. Майк утверждает, что 10 часов, потраченные на написание интеграционных тестов, тестов производительности и им подобных, сказываются неизмеримо сильнее на качестве программного продукта, нежели 10 часов, потраченные на написание модульных тестов.

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

По мне мотив второго пункта безусловно отчасти имеет место. Действительно, если рассмотреть мотивы властелинов дум, то к чему, казалось бы, так легко и бесплатно делиться идеями, которые представляются высокопродуктивными и перспективными? Бескорыстное желание двигать прогресс? И это в мире дикого капитализма? :) Возможно. Но почему бы, действительно, не рассмотреть мотив привлечения клиентов к своим консалтинговым услугам (хотя бы в качестве весомой составляющей)?Я утверждаю, что моя фирма впереди планеты всей так как использует передовые методики. Но не какие-то там абстрактные передовые методики (которых, на деле, может, и нет), а вот такие-то вполне конкретные методики. И не просто где-то надерганные методики, а методики, которые придуманы мною. И не просто придуманы и высосаны из пальца, а проверенные и апробированные сообществом разработчиков, которое я же и инспирировал. Понятно, что такой подход ставит меня, как властителя дум, выше моих последователей. И клиент при прочих равных условиях пойдет ко мне, а не к моему последователю. Но и последователи имеют свой кусок хлеба с маслом. С этой точки зрения мотивы властителей дум вполне понятны и, с моей точки зрения, вполне уважаемы. Это и есть, по сути, тот разумный эгоизм, о котором писал в свое время Чернышевский, и который, возможно, более ценен, чем голый альтруизм, зачастую не приносящий плодов. Это практический подход, который удовлетворяет все заинтересованные стороны.

Более интересен в этой статье пункт номер один. С утверждением автора статьи в этой форме вполне можно согласиться. Но есть одно «но» (и это упоминают некоторые комментаторы статьи)! В связи с модульным тестированием неизменно всплывает фигура еще одного «продажного» властителя дум Кента Бека, автора классического труда по TDD (Test Driven Development, разработка через тестирование). Именно Кент, кстати, является (в сотрудничестве с Эрихом Гаммой) автором программного продукта jUnit - прототипа xUnit (инфраструктур модульного тестирования для разных языков и платформ). Ненадолго отвлекшись на ActionScript, можно вспомнить реализованные для него инструменты: AsUnit (AS2/3), AS2Unit (AS2), Flex Unit (Flex AS2), ASTUce (AS1).

Так вот Кент Бек как раз предложил такую методику тестирования, которая едва ли не перебивает по ценности все остальные типы тестов. TDD использует модульные тесты не для тестирования уже написанного кода, а для разработки ненаписанного. Эта методика дает разработчику уверенность. Запуская тесты и видя зеленую полосу мы можем делать шаг вперед твердо зная, что у нас надежный тыл. 

Разработка по методике TDD состоит из следующих шагов:


  • Добавьте небольшой тест.

  • Запустите все тесты и убедитесь, что тест не сработал.

  • Внесите в код необходимые изменения.

  • Запустите все тесты и убедитесь, что все они сработали.

  • Выполните рефакторинг и удалите дублирование.


В сочетании с другими методиками, составляющими XP (eXtreme Programming, экстремальное программирование), это дает полную уверенность в процессе, предсказуемый результат и наличие работающего кода в любой момент времени. Что еще надо разработчику чтобы чувствовать себя уверенным и смело двигаться вперед? Ведь я знаю, что сделав что-то не то на одном из шагов, я буду тут же извещен (красная полоса!). Я всегда вижу луч света впереди (зеленая полоса).

Именно в этом и заключается ценность модульных тестов - они помогают разрабатывать код. Но есть еще и дополнительные ценности: тесты содержат в себе четкую и лаконичеую документацию о том, как следует использовать написанный код! Лучшей документации и не найти! И декларируемая в рамках XP и TDD простота (реализуй задачу самым простым способом, который только существует!) в сочетании с тестами - это надежная гарантия командной работы, которая не заведет в темный тупик.

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

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

Anonymous Майкл Клишин сообщает:

TDD штука опасная. Почти никто из начинающих просто не понимает, что поначалу она приведет к снижению скорости разработки, и только потом...
Сдаются. Но еще хуже тем, кто в тестах увязает. Увязает из-за плохого планирования или недостаточного знания ООП.

Так что начинать или нет -- вопрос самокритичности.

08 января, 2006 15:00  
Blogger Constantiner сообщает:

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

08 января, 2006 18:04  
Anonymous iv сообщает:

Так говорил учитель:
"Когда программа тестируется, уже слишком поздно вносить изменения в проект."
(Дао программиста)
http://permlug.org/data/docs/dzen/programmers_dao.html

11 января, 2006 15:16  
Blogger Constantiner сообщает:

:)

11 января, 2006 20:01  
Anonymous mrjazz сообщает:

Мои размышления привели меня к тому что для Flash, Html сайтов проще и нагляднее создать набор функциональных тестов, которые в любой момент могут показать как система работает. Т.е. просто специфика проектов такова что парой-тройкой кликов и проверкой контрольных значений провериться тонна кода, и если где то внутри него что то не так - это сразу выплывет. Пример утрированный конечно, но описывает ситуацию. Безусловно это идет в разрез с XP, в котором "первым делом самолеты", и вообще этот момент практичечки выпущен из обычных обсуждений (как по мне - незаслуженно). Для флеш я знаю только один инструмент функционального тестирования - http://osflash.org/autotestflash, и то - довольно сырой. Вышла одна версия и все на этом, а наворотить то на этом поприще можно солидный инструмент! Но... возможно уже сейчас кто то над этим трудиться.
Надеюсь я не слишком отошел от темы?

11 января, 2006 20:28  
Blogger Constantiner сообщает:

2mrjazz
Понятно, что функциональные тесты тестируют функционал. И автор статьи, по поводу которой я веду полемику так резонно полагает. Но Я-то как раз веду речь о "самолетах" и ценности модульных тестов в этом контексте. То есть, по сути, о том, что их никто не отменял и вряд ли это будет возможным :)

11 января, 2006 21:02  

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

Ссылки на пост:

Создать ссылку

Вернуться на главную