OpenQuality.ru

Качество программного обеспечения

Качество программного обеспечения: в главных ролях

Лента  Радар  Блог  Опыт  
Разум  Видео  Заметки  Эпизоды


Взлетная полоса, или введение в mock-объекты

Добрый день.

Чапаев: Петька, приборы! Петька: 300! Чапаев: Что 300? Петька: А что приборы?

Он пытался сопоставить скорость с потерей высоты, охваченный глубоким, вызывающим тошноту, ужасом от вида земли, неумолимо приближающейся с каждой секундой. Самолет переваливался с боку на бок, пропеллеры то замирали, то вновь начинали вращаться с бешеной скоростью. Через мгновение, показавшееся ему вечностью, колеса чиркнули по раскаленному асфальту, оттолкнулись, машина зависла в воздухе, но тут же, с ударом, опустилась на полосу… (по мотивам “Взлетно-посадочной полосы 08″ Артура Хейли).

Джордж Спенсер и все пассажиры самолета словно родились заново. Волею судьбы оказавшись в кресле первого пилота, Джордж сумел посадить лайнер, имея за плечали лишь опыт полетов на крошечном боевом истребителе во время войны. Кресло пилота гражданской авиации – одно из самых жестких. Множество датчиков, пультов, рычагов, мониторов, факторы внешней среды, взаимодействие с диспетчерскими службами, индивидуальные особенности воздушного судна – все не перечислишь. Подготовка пилота подразумевает отработку навыков поведения в стандартных и аварийных ситуациях. На помощь приходят тренажеры, которые воссоздают специфические рабочие нагрузки и состояния, возникающие в процессе управления самолетом.

Что представляет собой простейший тренажер? Некое подобие ответа Петьки из эпиграфа к данной статье. Прибор А – 300, прибор B – 500, и “ваше слово, товарищ маузер!”, как предлагал Маяковский. Иными словами, арию приборов исполняют заглушки, которые возвращают фиксированные значения. Есть буквы-цифры, и неважно, что за ними.

Что такое комплексный тренажер (Full Flight Simulator, FFS)? Максимально точное воссоздание стандартных процедур и внештатных ситуаций. От и до. Петька отдыхает, а Василий Иванович полностью погружается в состояние полета. Забыл про гидроусилитель? Не проверил удельный расход топлива? Не выпустил шасси? Авария, получите, распишитесь. Проанализируйте, что случилось, и начинайте заново.

Каждый компонент программной системы (возвращаемся к нашим баранам) подвергается интенсивным проверкам до сдачи в эксплуатацию. Отдельно взятый модуль зависит от других компонентов, и задействовать их не всегда представляется возможным. Вот несколько типичных ситуаций:

1. требуемый компонент еще не написан или же находится в неработоспособном состоянии. Скажем, если над ним работает другой программист.
2. искомый модуль недоступен. К примеру, сервлет, который находится на закрытом сайте.
3. необходимый интерфейс слишком “дорог”. Возьмем CУБД. Если тестируемый модуль обращается к базе данных, то хотелось бы избежать нагрузки на сервер.

Как поступать в таких случаях? Самый простой вариант – использовать заглушки (stubs). Мы рассматривали их реализации в Perl и Python. Они довольно удобны, если воспринимать мир вокруг нашего модуля как черный ящик. Неважно, что происходит внутри. Важно, что на выходе. “Петька, приборы!” – “300″, и вся недолга. Но такой вариант подходит не всегда. Предположим, наша программная система анализирует финансовое состояние компании. В простейшем виде, прибыль = доход – издержки. Если нашему компоненту нужно знать прибыль, то ему можно подложить 300 и сказать, что это прибыль. А можно убедиться в том, что величина прибыли не берется “с потолка”. Можно убедиться в том, что при запросе прибыли действительно вычисляются доход и издержки (вызываются соответствующие методы класса), и в случае получения 700 рублей дохода и 400 рублей издержек мы таки получим 300 рублей прибыли. Такая проверка позволит быть уверенным в том, что изменение/расширение программной системы не повлекло за собой несанкционированное изменение поведения системы, и алгоритм расчета прибыли остался именно таким, каким он предполагался быть. Именно этим и занимаются имитаторы (mocks).

Имитаторы позволяют воссоздавать поведение системы, не нарушая ее работы и даже не имея ее под рукой. Например, в клиент-серверном приложении можно имитировать работу сервера и полноценно тестировать клиент. Или выполнить псевдоконнект к базе, “записать” строку в таблицу, вернуть результат, и при этом даже не обращаться к серверу баз данных. Или имитировать ситуацию, трудно воспроизводимую в реальной среде, но реакция на которую нам важна – например, исключение (exception), генерируемое при высоких нагрузках. Здорово, правда?

Для современных языков программирования написано немало модулей, которые позволяют создавать mock-объекты “на лету” и “с пылу, с жару” использовать их в модульных тестах. В то же время, хочется отметить, что mock-объекты – это не серебряная пуля. В каких случаях применение имитаторов может оказаться неэффективным? Вот несколько сценариев:

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

Каждая программная система уникальна. Архитектура приложения и сопутствующие обстоятельства диктуют выбор в пользу имитаторов, заглушек или даже отсутствия тех и других. Как бы то ни было, выбор будет тем надежнее, чем лучше мы знаем свое приложение и практики создания модульных тестов.

Примеры создания имитаторов мы рассмотрим в одной из следующих статей. Оставайтесь с нами и зовите друзей. До встречи.

Отправить в Twitter, Facebook, ВКонтакте | Опубликовано 13.05.2009 в рубрике "Модульные тесты"

Комментарии (4)

  1. Pingback : OpenQuality.ru | Python: модульное тестирование с MiniMock | June 2, 2009

    […] Более подробную информацию о MiniMock можно получить в документации к модулю. Помимо этого, будет полезно ознакомиться с кодом minimock.py (доступен в архиве MiniMock-1.2.3.tar.gz). Он небольшой, но достаточно информативный. Каждый класс снабжен описанием и примерами его использования. Счастливого взлета. […]


  2. Pingback : OpenQuality.ru | Качество программного обеспечения | December 13, 2010

    […] ввода-вывода. Могут оказаться полезны заглушки (stubs) и имитаторы […]


  3. Автор комментария : ffs | January 17, 2012

    “Что такое комплексный тренажер (Full Flight Simulator, FSS)? ”

    Наверное, надо написать FFS, а не FSS?

    [Ответить]


  4. Автор комментария : Капитан | January 25, 2012

    Да, опечатка. Спасибо!

    [Ответить]



Добавить комментарий

Пожалуйста, исправьте результат: дважды два равно



КРАТКОЕ СОДЕРЖАНИЕ

Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.


ПУТЕВОДИТЕЛЬ

Проект был основан в 2008 году. За это время часть статей устарела, а некоторые из них вызывают улыбку, но пусть они останутся в том виде, в котором были написаны. Cписок всех статей с краткой аннотацией и разбивкой по рубрикам: открыть.

ПОДПИСКА

Доступ к самым интересным материалам по электропочте и RSS. Подробности.

ИЩЕЙКА