Просмотр исходного текста страницы Автоматические модульные тесты при разработке корпоративного ПО

<blockquote>
''В журнале [http://it-world.ru/it-media/covers/itnews/189/ IT News (№7/2012)] опубликована [http://www.it-world.ru/it-media/pdf/itnews/189/#/16/ статья] ведущего разработчика [[:Категория: Андрей Ковалев (Статьи)|Андрея Ковалева]] «Автоматические модульные тесты при&nbsp;разработке корпоративного ПО». Андрей рассказывает, как и&nbsp;когда появилась идея написания автоматических тестов и&nbsp;какие плюсы дает их&nbsp;применение, а&nbsp;также пытается разобраться, почему, несмотря на&nbsp;все положительные эффекты, они так редко используются на&nbsp;практике.''
</blockquote>

'''Что произойдет, если в&nbsp;программу поступят данные, которые изначально не планировались? Или в&nbsp;настройках новой версии программы неправильно указан какой-то, казалось бы, не&nbsp;очень важный параметр? Справится ли код с&nbsp;такой ситуацией, выдаст ли программа адекватное сообщение об&nbsp;ошибке или на&nbsp;экране появятся малопонятные символы и&nbsp;последует сбой, парализующий работу пользователя и, возможно, бизнес-процесс?'''

Пожалуй, наиболее эффективным способом убедиться, что программа работает должным образом, является автоматическое тестирование кода. Оно позволяет гарантировать корректную работу программы не&nbsp;только в&nbsp;типовых, но и&nbsp;в&nbsp;нестандартных ситуациях, а&nbsp;также при&nbsp;последующих изменениях системы (например, при&nbsp;выпуске новых версий). Автоматические тесты особенно актуальны для&nbsp;крупных информационных систем, которые планируется развивать и&nbsp;поддерживать.

Идея написания автоматических модульных тестов (называемых также unit-тестами) при разработке ИС появилась в&nbsp;70-х&nbsp;годах прошлого века и&nbsp;была впервые реализована с&nbsp;помощью языка программирования Smalltalk. Однако практическое их&nbsp;применение при&nbsp;создании ИС уровня предприятия началось не&nbsp;так давно. Технология в&nbsp;ее современном виде впервые описана в&nbsp;методологии экстремального программирования (Extreme Programming), представленной Кентом Беком (Kent Beck) в&nbsp;1999&nbsp;году. Впрочем, идеи автоматизированного тестирования продолжают развиваться и&nbsp;по&nbsp;сей день. Так, например, в&nbsp;гибкой методологии ATDD (Acceptance Test-Driven Development) предполагается переход от&nbsp;модульных (unit) к&nbsp;приемочным (acceptance) автоматическим тестам. Остальные гибкие методологии не&nbsp;настолько радикальны.

В&nbsp;настоящее время автоматические тесты доказали свою эффективность и&nbsp;все чаще применяются при разработке программного обеспечения. Однако на&nbsp;конференции Microsoft «Платформа-2011» произошел любопытный случай. Один из&nbsp;ключевых докладчиков, Дэвид Чеппелл (David Chappell), обратился к&nbsp;залу с&nbsp;просьбой поднять руки тех, в&nbsp;чьих компаниях при разработке ПО используются автоматические модульные тесты. Таковых оказалось лишь несколько человек. Дэвид был очень удивлен и&nbsp;громко воскликнул: «Why?!» (корпорация Microsoft уже с&nbsp;2005&nbsp;года предоставляет поддержку автоматических тестов в&nbsp;своих инструментах для&nbsp;разработчика).

= Зачем это нужно? =

Разработчики часто сталкиваются с&nbsp;ситуацией, когда при изменении какого-либо ключевого алгоритма, используемого в&nbsp;нескольких местах системы, в&nbsp;зависимых частях также могут произойти изменения, в&nbsp;том числе непредсказуемые. Автоматические тесты выявляют возможные ошибки еще на&nbsp;этапе разработки, позволяя модифицировать имеющийся код без риска его «сломать». Поэтому код, «покрытый» тестами, удобен в&nbsp;обслуживании и&nbsp;сопровождении, пригоден для&nbsp;повторного использования и&nbsp;более надежен.

Автоматические тесты экономят время как первоначального тестирования кода разработчиком (открытие форм, ввод данных, ожидание…), так и&nbsp;последующего регрессионного тестирования (благодаря таким тестам, его можно частично автоматизировать, то&nbsp;есть избавиться от&nbsp;избыточности).

Еще одним достоинством автоматического тестирования является то, что оно помогает не&nbsp;только проверять стрессоустойчивость системы, но и&nbsp;определять производительность ее&nbsp;отдельных частей. Кроме того, использование автоматических тестов «вынуждает» разработчика улучшать качество кода: тщательно продумывать архитектуру приложения, разделять слои, отделять логику работы с&nbsp;базой данных от&nbsp;бизнес-логики, использовать преимущества объектно-ориентированного программирования, чаще применять шаблоны проектирования. Существует целая методология разработки «через тестирование» (Test-Driven Development), в&nbsp;соответствии с&nbsp;которой сначала пишется модульный тест, проверяющий ожидаемое поведение, и&nbsp;только после этого&nbsp;— сам код.

= А как без них? =

В двух компаниях, где я&nbsp;работал раньше, написание автоматических модульных тестов считалось ненужным и&nbsp;не&nbsp;практиковалось. При этом если в&nbsp;одной компании (назовем ее А) существовал целый отдел тестирования, то&nbsp;другая (Б) перекладывала тестирование продукта на&nbsp;конечного пользователя. Стоит признать, что ни&nbsp;первый, ни&nbsp;второй вариант не&nbsp;был особо эффективным.

Так, в&nbsp;компании&nbsp;А процесс разработки и&nbsp;тестирования постоянно затягивался, а&nbsp;количество тестовых случаев (test cases), требующих ручной проверки, росло как снежный ком. Кроме того, эти узкие места приходилось вручную перепроверять в&nbsp;каждой новой версии продукта, отдавать программу обратно на&nbsp;доработку, ждать исправлений, перепроверять заново и&nbsp;т.&nbsp;д. Не стоит забывать и&nbsp;о&nbsp;человеческом факторе: специалист отдела тестирования может банально забыть проверить что-то или понадеяться, что если некий функционал работал в&nbsp;прошлой версии, то будет работать и&nbsp;в&nbsp;новой. А&nbsp;вот компания&nbsp;Б, наоборот, довольно быстро выпускала новые версии продукта, однако, что неудивительно, постоянно получала жалобы от&nbsp;пользователей. Доработка продукта была также очень непростым делом, поскольку никто не&nbsp;мог дать гарантии, что при изменении функциональности какого-нибудь блока построения диаграмм не&nbsp;«сломается» что-то другое.

Общей проблемой обеих компаний было то, что&nbsp;найденные и&nbsp;вроде бы когда-то исправленные ошибки появлялись вновь. Кроме того, нельзя забывать, что при устранении одной ошибки всегда есть риск внести другую, которая проявится позже и&nbsp;в&nbsp;другом месте. Обе эти проблемы успешно решаются с&nbsp;помощью автоматических тестов, которые «отлавливают» повторно возникающие ошибки еще на&nbsp;этапе разработки и&nbsp;позволяют каждый раз после внесения изменений быстро убедиться, что программа работает должным образом.

= Не панацея =

Безусловно, автоматические тесты не&nbsp;лишены некоторых недостатков. Первый и, наверное, основной из них&nbsp;— дополнительные затраты на&nbsp;написание и&nbsp;поддержку автоматических тестов. Грубо говоря, вместо одной ИС мы&nbsp;получаем две, одна из&nbsp;которых занимается автоматической диагностикой другой. Однако, что любопытно, большая часть времени разработчика уходит отнюдь не&nbsp;на&nbsp;кодирование функционала. Здесь уместна цитата Мартина Фаулера (Martin Fowler), известного автора ряда книг по&nbsp;архитектуре ПО: «Некоторое время уходит на&nbsp;уяснение задачи, еще какая-то его часть&nbsp;— на&nbsp;проектирование, а&nbsp;львиную долю времени занимает отладка»<ref>Рефакторинг. Улучшение существующего кода. — СПб.: Символ-Плюс, 2003.</ref>.

Действительно, на&nbsp;написание тестов и&nbsp;их поддержку требуется дополнительное время, однако эти затраты, скорее всего, позволят выиграть время впоследствии, при&nbsp;отладке и&nbsp;выявлении ошибок, а&nbsp;если появятся новые требования&nbsp;— то и&nbsp;при&nbsp;расширении системы. Но если не&nbsp;учитывать дальнейшие перспективы, может сложиться впечатление (в&nbsp;том числе и&nbsp;у&nbsp;заказчика), что разработка с&nbsp;использованием автоматических тестов занимает больше времени, чем без тестов, и, соответственно, стоит дороже.

Второй недостаток заключается в&nbsp;том, что автоматические модульные тесты делают разрабатываемую программу несколько более инертной. Это связано с&nbsp;тем, что внесение изменений в&nbsp;систему, «покрытую» автоматическими тестами, занимает больше времени, поскольку, помимо самой системы, их нужно вносить в&nbsp;тесты. Этот фактор может стать существенным, когда заказчик требует сделать в&nbsp;программе «срочные» изменения в&nbsp;очень сжатые сроки (к&nbsp;примеру, за&nbsp;несколько часов).

Третий недостаток автоматических тестов связан с&nbsp;их неспособностью заменить «ручное» тестирование. Действительно, сложно представить автомобиль, который полностью сам себя диагностирует и&nbsp;выдает точное место поломки с&nbsp;рекомендациями.

Однако автоматическое и&nbsp;«ручное» тестирование прекрасно дополняют друг друга. Автоматические тесты уменьшают количество рутинной работы, сокращают общее время регрессионного тестирования и&nbsp;позволяют сосредоточиться на&nbsp;«ручном» тестировании нового функционала. То&nbsp;есть автоматические модульные тесты помогают избавиться от&nbsp;избыточного «ручного» тестирования.

Следует иметь в&nbsp;виду (и&nbsp;это можно с&nbsp;некоторой долей условности назвать четвертым недостатком), что с&nbsp;помощью автоматических тестов нельзя протестировать абсолютно все. Не стоит доходить до&nbsp;абсурда и&nbsp;создавать чрезмерно сложные тесты, иначе на&nbsp;их&nbsp;написание и&nbsp;последующую поддержку уйдет слишком много времени, и&nbsp;они станут действительно невыгодны в&nbsp;плане трудо- и&nbsp;временных затрат.

О невозможности «всеохватного» тестирования пишет и&nbsp;Кент Бек, уже упомянутый нами создатель методологии экстремального программирования: «Протестировать абсолютно все невозможно&nbsp;— для этого тесты должны быть столь же сложными и&nbsp;столь же беззащитными перед ошибками, как и&nbsp;сам код приложения. Ничего не&nbsp;тестировать (в&nbsp;смысле изолированных автоматических тестов)&nbsp;— это самоубийство»<ref>Экстремальное программирование. — СПб.: Питер, 2003.</ref>.

Автоматические тесты давно стали не&nbsp;инновацией, а&nbsp;в&nbsp;некотором роде стандартом при&nbsp;разработке корпоративного ПО. Их использование обеспечивает более высокое качество кода и, соответственно, программного обеспечения в&nbsp;целом, помогая заметно повысить надежность системы. Однако из-за ограничений архитектуры разрабатываемого програмного продукта, а&nbsp;также по&nbsp;причине сложности написания действительно качественных и&nbsp;полезных тестов автоматическое модульное тестирование применяют не&nbsp;все компании, разрабатывающие ПО.


[[Категория: IT News (Публикации)]]
[[Категория: Андрей Ковалев (Статьи)]]
[[Категория: 2012 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}