Unit-тестирование в аутсорсинге

Unit-тестирование в оффшорной аутсорсовой модели разработки ПО имеет достаточно интересную специфику. С одной стороны, почти все программисты и даже некоторые менеджеры знают, что написание unit-тестов – это полезная практика, которая помогает создавать более стабильный, качественный и модифицируемый код. С другой стороны лишь небольшое количество проектов имеют хотя бы какие-нибудь unit-тесты, а те проекты, на которых unit-тесты живут и развиваются – вообще единичные случаи. Сразу скажу, что я буду говорить в основном о компаниях города Харькова, т.к. знаю я по большинству лишь харьковский рынок, но мне кажется, что какие-то результаты анализа можно аппроксимировать на всю отрасль в целом.

Прежде всего, нужно определиться, зачем вообще нужно unit-тестирование:

• Unit-тестирование дает уверенность, что код работает как нужно хотя бы при положительном тестировании, то есть, когда мы проверяем его лишь с точки зрения правильного результата.
• Оно также позволяет проверить граничные и неправильные входные данные, которые могут попасть на вход определенному участку кода (отрицательное тестирование) и, соответственно, поставить дополнительную защиту в таких случаях (проверка NullReferenceException и прочее).
• Наверно, самый основной пункт – более безопасное изменение функциональности и рефакторинг: unit-тесты можно сравнить с парашютом, который спасает программиста, если тот в своем желании что-то исправить зайдет слишком далеко и сломает другие части системы.
• Unit-тесты защищают приложение от переоткрытия старых дефектов, когда уже были однажды исправлены. Для этого перед тем, как делать исправление, нужно написать unit-тест, который воспроизводит ошибку, потом исправить ее и запустить тест заново. Во-первых, это быстрая проверка исправления, во-вторых, постоянный запуск теста в будущем даст возможность быть уверенным, что ошибка не воспроизведется.
• Unit-тесты также снижают время на тестирование и отладку приложения, т.к. очень много дефектов вылавливается автоматически самими тестами, а не QA.
• В это сложно поверить, но unit-тесты поощряют отделение интерфейса от реализации, использование паттернов проектирования, уменьшают связность кода (coupling) и, в целом, улучшают код. Связано это прежде всего с тем, что для того, чтобы протестировать метод, часто нужно сделать дополнительные операции – создать заглушки или моки, передать их в нужный класс/метод. Иногда тестируемый метод настолько велик, что его стоит разделить на несколько более мелких и т.д.
• Ну, и последнее: написание unit-тестов позволяет глубже понять тестируемый код и, соответственно, сделать его более качественным.

Все, что я перечислил, не является чем-то принципиально новым. Многие западные программисты уже давно взяли unit-тесты себе на вооружение. Концепция unit-тестирования и рефакторинга существует уже больше 10 лет. Количество unit test и mock фреймворков постоянно растет, создаются целые методологии и практики по использованию unit-тестов в разработке программного обеспечения (одна из практик XP, Test Driven Development, рефакторинг, CI и т.д.). Есть куча англоязычных форумов, блогов, статей, посвященных этому вопросу. В то же время, когда смотришь на разработку ПО в нашей стране, создается впечатление, что мы застряли в каменном веке :) Однако, такому положению дел есть достаточно простое объяснение: несмотря на то, что полезность unit-тестов трудно оспорить, выгодны они далеко не всегда.

Есть как минимум несколько отрицательных сторон unit-тестирования:

• Написание unit-тестов занимает время. Согласно различным исследованиям, написание unit-тестов увеличивает процесс написания кода в среднем в 2 раза. Часто этого времени нет или это время дорого.
• Unit-тесты требуют постоянной поддержки, что также увеличивает время разработки приложения. Здесь особых цифр нет, но, думаю, это увеличивает время еще процентов на 5-10.
• Не весь код легко протестировать при помощи unit-тестов (например, UI). Создание поддержки таких тестов часто требует колоссальных трудозатрат.
• Ну, и наконец, программисты ленивы, а написание тестов – это достаточно рутинная задача, поэтому программисты зачастую не любят/хотят писать unit-тесты.

Почему же тогда в некоторых случаях unit-тесты помогают в процессе разработки, а в некоторых – мешают ей? И самое главное: в каких случаях их стоит писать, а в каких – нет? Это была присказка, дальше идут во многом мои размышления, вам виднее, соглашаться с ними или нет.

Если проанализировать существующее положение дел, то можно увидеть, что unit-тесты в большинстве своем используются либо в компаниях-лидерах разработки ПО, где с охотой применяются различные нововведения в индустрии, либо в компаниях, которые разрабатывают свое ПО в течение многих лет. И это, в принципе, понятно. Несмотря на то, что unit-тестирование – уже не молодая техника, успешно и более-менее массово ее начали применять лишь недавно, с появлением гибких методологий и развития теоретической базы: появления концепции рефакторинга кода, подходов к рефакторингу и целых методологий написания кода на базе unit-тестирования, например, TDD. Рефакторинг без unit-тестов становится очень опасным занятием, поэтому они часто идут в паре. Кроме того, unit-тесты особенно полезны в тех случаях, когда код достаточно часто меняется, а не просто сидит сиднем, становясь со временем legacy-кодом, в который все боятся лезть. А вот это как раз больше подход к разработке больших приложений в течение многих лет, когда выходят новые версии, содержащие какие-нибудь усовершенствования и новые фичи. В таких приложениях качество – превыше всего и unit-тесты позволяют его достичь.

В то же время оффшорная аутсорсовая разработка – это зачастую разработка не таких долгостроев, а даже если это и долгострой, то клиента очень часто больше волнуют бюджет и сроки, и в меньшей степени – качество (а иначе, зачем он тогда отдал разработку в оффшор, а не сделал заказ у себя на родине, где и качество будет выше, и цена в разы больше). Такому клиенту будет сложно «продать» идею unit-тестирования, ведь часто бывает, что клиент даже обычное тестирование не хочет проводить, считая, что это могут сделать и программисты. И так сроки и бюджет поджимают, не до абстрактных преимуществ какой-то новомодной практики. Хотя, справедливости ради нужно сказать, что для многих типов приложений unit-тесты – это действительно избыточность. Если вы пишете небольшое приложение, в котором нет серьезных участков кода, требующих частых изменений, unit-тесты вам, возможно, и не нужны. Основная мощь unit-тестов – в их возможности быстро одернуть программиста, когда он внес в приложение код, разрушающий существующий функционал, а это очень часто ведет к тому, что дефект уходит в production, так как полное функциональное тестирование в конце жизненного цикла разработки на проектах бывает далеко не всегда.

На своем личном опыте я могу сказать, что из около 10 компаний города Харькова, о которых я что-то знаю, unit-тестирование хотя бы в каком-то виде есть лишь где-то на 15-20% проектов, а в полной мере оно используется и того реже.

Итак, попробуем понять, когда unit-тестирование полезно в аутсорсовой модели разработки и как лучше его использовать:

• В динамически меняющемся приложении (например, если разработка идет по agile-методологии с постоянно меняющимися требованиями) unit-тесты могут, за счет увеличения времени разработки, существенно уменьшить время на отладку, тестирование и багфиксинг. В целом, затраты на последующую отладку зачастую компенсируют накладные расходы во время разработки.
• В крупных или критичных к качеству приложениях unit-тесты могут существенно повысить качество результата и процесса в целом. Если у вас приложение такого типа, не раздумывайте долго – unit-тестирование вам необходимо.
• Необходимо не забывать, что покрытие тестами 100% кода не защитит вас от ошибок, но лишь уменьшит их, поэтому 100%-ное покрытие не имеет особого смысла. В идеале unit-тестами должен быть покрыт лишь сложный и часто меняющийся код, в котором вероятность появления дефектов при изменении или рефакторинге выше, чем в остальном коде.
• Для того чтобы уменьшить время на переделку тестов, лучше сразу же хорошо продумать архитектуру и дизайн приложения. Этот совет хорош не только с точки зрения unit-тестов, но и просто с точки зрения разработки ПО.
• Для того чтобы уменьшить время на само написание тестов, лучше сразу стараться пользоваться различными паттернами проектирования, выделять интерфейсы, уменьшать связность кода. Опять же, совет касается не только и столько unit-тестирования, сколько разработки в целом.
• Для избежания появления уже однажды исправленных дефектов следует писать unit-тесты на дефект перед тем, как исправлять его.
• Для более систематического написания тестов можно применить какой-нибудь систематический подход к написанию unit-тестов, например, TDD. Это сложно и требует перестройки мозгов программистов, но практики TDD уверяют, что это дает отличные результаты в дальнейшем.
• Внедрять unit-тесты, конечно же, проще на новом коде, на существующем же legacy-коде можно ввести следующее правило: не делать изменения в нем до тех пор, пока не будет написано несколько небольших тестов, проверяющих правильность его работы. Это даст возможность не только со временем покрыть тестами старый код, но еще и обезопасить себя от возможных последствий своих изменений.
• Во многих случаях для написания unit-теста на метод необходимо серьезно извратиться, чтобы поставить заглушки на все внешние методы, которые вызывает тестируемый метод. Здесь можно посоветовать использовать любой из существующих mock фреймворков, например, Rhino Mocks, Moq или TypeMock.Net. Положа ногу на сердце, я бы рекомендовал Rhino Mocks, но иногда нужна мощь TypeMock.Net, или простота Moq – выбирайте, что вам больше по душе и по карману. Более подробно про моки и заглушки я расскажу в следующий раз.
• Если вы понимаете, что на вашем проекте unit-тестирование нужно как воздух, а клиент не хочет и слушать об этом, вооружитесь аналитикой и опишите клиенту все «за» и «против» unit-тестов. Написание базовых тестов на основные классы и методы не займет много времени, но поможет вам сэкономить кучу времени в дальнейшем и, что более важно, поможет сделать продует более качественным и надежным.
• Как я уже говорил, не все программисты любят писать тесты. Их тоже нужно расшевелить, как и клиента, показать достоинства, сделав обязанность писать тесты не каторгой, а приятной рутиной, которая позволяет уберечь себя в будущем от серьезных проблем.
• Ну, и наконец, даже если вам сильно понравилась идея unit-тестирования, не забывайте, что, возможно, оно вам и не нужно. Действуйте прагматично и рационально. Не нужно бегать за всеми нововведениями в мире разработки ПО – это чревато.

А у вас на проекте используются unit-тесты? Какие практики вы используете, какие шишки набили?