CC BY
65
УДК 004.054
Д. H. МАТВИЕНКО
Омский государственный технический университет
ОСОБЕННОСТИ ТЕСТ-ОРИЕНТИРОВАННОЙ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Проведен анализ возможности применения методик тест-ориентированной разработки при создании программных средств на интерпретируемых языках программирования (на примере PHP). Рассмотрены особенности работы с «унаследованным» программным кодом.
Ключевые слова: методика, тест-ориентированная разработка, открытое программное обеспечение, модульные и общие тесты.
Опыт создания и применении сложных информационных систем (ИС) в последние десятилетия вы-инил множество си туаций, при которых сбои и отказы систем были обусловлены дефектами комплексом программ и сопровождались большим ущербом.
При существующем уровне развития методов, технологий и средств автоматизации проектирования есть предельные масш табы и объемы комплексов программ, после достижения которых невозможно обеспечить при допустимых затратах необходимую надежнос ть функционирования программных средств (ПС).
Как правило, для создания информационных систем используются комплексы программ, содержащие различные дефекты проектирования и программирования (уровень которых априори неизвестен), снижающие надежность функционировании программного комплекса в целом.
В течение всего жизненного цикла на программные средства воздейс твуют различиые дестабилизирующие факторы, которые можно разделить на внутренние, присущие1 самим объектам уязвимости, и внешние, обусловленные средой, в которой эти объекты функционируют.
Внутренними источниками угроз надежности функционирования сложных программных средств можно назвать следующие дефекты программ:
— системные ошибки при постановке целей и задач создании ПС, при формулировке требований к функциям и характеристикам решения задач, определении условий и параметров внешней среды, в которой предстоит применять ПС;
— алгори тмические ошибки разработки;
— ошибки программировании в текстах программ и описаниях данных, а также в исходной и резуль тирующей документации на компоненты и ПС в целом;
— недостач-« активность используемых методов и средств оперативной защи ты программ и данных от сбоев и отказов в условиях случайных негативных воздействий.
Внешними дестабилизирующими факторами, о тражающимися на надежности функционировании ПС, являются:
— ошибки оперативного и обслуживающего персонала в процессе эксплуатации;
— искажения в каналах телекоммуникации информации, поступающей от внешних ис точников и передаваемой потребителям, а также недопустимые
для конкретной информационной системы характеристики потоков внешней информации;
— сбои и отказы в аппаратуре вычислительных средств;
— изменения состава и конфигурации комплекса взаимодействующей аппаратуры информационной системы за пределы, проверенные при испытаниях или сертификации и отраженные в эксплуатационной документации.
Полное устранение перечисленных негативных воздействий и дефектов принципиально невозможно.
Возникла необходимость при разработке масштабных проектов использовать определенный инструментарий, позволяющий ав тома тизирова ть управление качеством программного обеспечения. Одним из возможных вариантов подобной автоматизации является применение тест-ориентированной разработки.
Разработка через тестирование (Test Driven Development, TDD) — процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.
Модульные тесты (Unit Tests) — тес ты, провери-ющие функциональность отдельных классов, компонентов, модулей приложения. Эти тесты не видны конечному потребителю программного продукта.
Функциональные или общие тесты (General Tests) - тесты, проверяющие функционирование программного продукта в целом. При необходимости результаты данных тестов могут быть выведены дли ознакомления пользователя или заказчика.
Разработка через тестирование обладает рядом несомненных преимуществ и уверенно доказывает свое право на существование и дальнейшее развитие. В качестве основных достоинс тв TDD можно назвать: повышение качества разработки на всех этапах жизненного цикла программного комплекса за счет снижении влияния человеческого фактора и определенной автома тизации процесса разработки;
— прогнозируемое1 время завершения масштабных проектов благодари исключению этапа «классической» отладки, который практически не имеет формальных методов оценки временных затрат;
разделение бизнес-логики и интерфейсов1 при-
' Здесь« далее под интерфейсом подразумевается способ орган и наци и н.ыимодейстпия между модулями одного программного продукта
105
12287813
Рис. 1. Цикл разработки и TDI)
ложения, упорядочение структуры программною кода.
С практической точки зрения основой TDD являем ся цикл «тест/код/рефакторинг». 15 первой фазе про-граммисг пишет тест, во второй — код необходимый для того, чтобы тест работал, в третьей, при необходимости, производится рефакторипг (переработка). Последовательность фаз очень важна (рис. I). В соответствии с принципом «Tesl First» («Тоствпервуюочередь») следует писать только такой код который абсолютно необходим, чтобы тесты выполнялись успешно.
Модульное тестирование играет важную роль в качестве средства оптимизации дизайна. Чтобы написать гест, необходимо де тально продумать интерфейс проектируемого модуля и про токол его использования. Что еще более важно, тестирование в рамках TDD позволяет получить прос той способ оценки пол-поты интерфейсов: необходимым и достаточным считается такой объем кода, который позволяет выполнить все написанные тесты. Веч;, что находится за этими рамками, считается ненужным. Наконец, использование тестов в качестве инструмента дизайна заставляет программис та в первую очередь концентрироваться на т ребуемой функциональности, а уже во вторую — на применяемых методах, что также положительно влияет на результат.
Многие программисты, однажды попробовав работать в стиле TDD, сталкиваются с многочисленными проблемами и бросают тестирование. Они отмечают, что модульное1 тестирование усложняет процесс разработки, делает ei'o слишком медленным и более трудоемким из-за возрастающего объема тестового кода, который слишком сложно поддерживать.
TDD — это процесс итеративного, непрерывного написания тестов и рабочего кода, с обязательными фазами рефакториига 11 ]. При разработке в рамках TDD необходимо стремиться минимизировать размер контекста, в котором в данный момент ведется разработка. Это относим ся как к тест у, так и к рабочему коду. Необходимо писать тосты очень мелкими шагами и не пытаться представить, как будет выглядеть окончательный код. Даже если очевидно, как
будут построены все остальные тесты и сам рабочий кодмодуля, желательно предпочесть написать короткий тест, затем небольшую часть рабочего кода. Конечно, каждый самостоятельно может определять, ч то для него «небольшие шаги», но общая рекомендация такая — стараться сокращать промежутки между запусками тестов. При активной разработке имеет смысл запускать тесты раз в 2-3 минуты и даже чаще. Это позволяет проверят!, написанный код сразу же, не теряя кон текста, то есть, помня все детали только что измененного кода.
Обязательным условием успешного внедрения TDD является фаза рефакториига. После получения рабочего кода необходимо обязательно критически посмотреть на код и сдела ть хотя бы несколько шагов для улучшения его читабельности и понятности. Идеально, если после рефакториига код вообще бы не требовал комментариев.
TDD :>то набор лучших практик, зарекомендовавших себя в разработке программного обеспечении. Многие разработчики отметили, что внедрять TDD лучше всего или на новом проекте (можно учебном), или же с отдельных классов. Не рекомендуется начинать внедрениеTDD на реальных коммерческих проектах, особенно на больших и со сложным наследием. Без «унаследованного» кода (legacy code) внедрять TDD намного проще, так как в этом случае есть возможность полностью контролировать ситуацию и принимать какие угодно решения. Начинать внедрение модульного тестировании лучше небольшими шагами и по направлению «снизу вверх» (рис. 2).
Тем не менее в ряде случаев существует необходимость применения тестов к уже существующему проекту. Рассмотрим подобную ситуацию более подробно.
Самым сложным шагом в освоении TDD является, что не удивительно, самый первый. Многие разработчики с радостью мечтают перейти от хаосиой разработки к TDD, однако проблема первого шага (а точнее; вопрос, «А с чего же, собственно, начать?») не позволяет им сделать этого.
Начало
Оценка достаточности проведенного тестирования
Да
Окончание процесса отладки
Рис. 2. Модель разработки «снизу вверх»
Еще более непреодолимым препятс твием являе тся уже существующий код, который в нрипципетруд-но протестировать, т.к он разрабатывался не в рамках TDD. Но действительно ли сложности столь велики?
Попытаемся показать на примере, ч то практически любое существующее приложение можно перевести на «рельсы» TDD, используя определенпыетех-ники тестирования. Типичный набор приемов в данном случае может выглядеть так.
1. Создаем функциональные 'тесты, которые помогут тестировать приложение в общем.
2. Отделяем логику обработки данных от представления.
3. Создаем модульные тесты.
Двигаться следует небольшими шагами по следующему плану:
1. Используем SimpleTest (версия 1.0, http:// simplctesl.sourceíorqe.nol) в качестве среды для функционального и модульноготестирования.
2. Используем WACT (версия 0.2alpha, http:// wacl.sourceforqe.net) в качестве шаблонной системы'' и в качестве DBAL (Dalabase Abstraction Layer)
Основная задача тестирования и отладки функций программных модулей состоит в проверке корректности обработки модулями поступающей информации и получающихся на выходе данных в соответствии с функциями, представленными в спецификациях. Должна быть проверена корректность структуры модулей и примененных конструктивных компонент: циклов, блоков, переключателей и •т.д. Относительная простота используемых компонент и их взаимодействия позволяет осуществлять весьма полное детерминированное тестирование и контролировать достигаемое качество программ.
Тес тирование целесообразно планировать с учетом конкретной структуры модулей и особенностей обработки потоков информации. Высокая автоматизация и упорядочение процесса тестирования обеспечивают гарантии качества программных модулей и многокра тное применение типовых тестов в различных версиях программных средств.
Таким образом, подтверждается предположение о возможности использования тесг-ориептировапной разработки как в проектах, создаваемых «с нуля», так и в уже существующих программных комплексах, обладающих значительными объемами «унаследованного» кода.
В настоящее время описанные методики тестирования применяются при проектировании н разработке программного комплекса СУБД «Деканат» на базе Омского государственного технического университета. Разработанная информационная система представляет не том.ко практическую, но и научную ценность, т.к. позволяет пронести исследона-ние работы методов тест-ориентированной разработки в программе, реализованной на интерпретируемом языке программирования и обладающей значительным объемом «унаследованного» кода.
ЬпОлпографический список
I Пек К. Тест-ориентированмая разработка в примерах. - М : Вильяме. - 2002. - 212 с.
МАТВИЕНКО Дмитрий Николаевич, аспирант кафедры «Информационно-измерительная техника».
Дата поступления статьи в редакцию: 01.10.2008 г. © Матвиенко Д.11.
