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

Наткнулся на интересную статейку написанную 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 простота (реализуй задачу самым простым способом, который только существует!) в сочетании с тестами - это надежная гарантия командной работы, которая не заведет в темный тупик.

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