Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

Питер: «Понятно. А как будет называться файл?»

Пола: «Я думаю, log.backup подойдет».

Питер: «Хорошо».

В другом офисе Сэм общается по телефону с заказчиком.

Сэм: «Да, да, журнальные файлы будут сохраняться».

Карл: «Очень важно, чтобы ни один журнал не был потерян. Нельзя исключать, что нам придется когда-нибудь вернуться к любому из этих файлов, даже через месяцы или годы – в случае сбоя питания, какой-нибудь катастрофы, судебного спора и т. д.».

Сэм: «Не беспокойтесь, я только что говорил с Полой. Журналы будут сохраняться в каталоге с именем backup ежедневно в полночь».

Карл: «Хорошо, это подойдет».

Вы заметили неоднозначность? Заказчик ждет, что сохраняться будут все журналы, а Пола думает, что достаточно сохранить журнал за последний день. Если заказчик захочет вернуться к резервной копии месячной давности, он найдет только данные последнего дня.

В данном случае и Пола, и Сэм оказались не на высоте. Профессиональные разработчики (и менеджеры) должны следить за тем, чтобы из требований была исключена всякая неоднозначность.

Это сложная задача, и мне известен только один способ ее решения.

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

Одна из самых распространенных неоднозначностей, с которыми сталкиваются профессиональные разработчики, связана с самим понятием «выполнения». Когда разработчик говорит, что он выполнил свою задачу, что он имеет в виду? Что он готов передать свой код в эксплуатацию с полной уверенностью? Что его код готов к прохождению контроля качества? А может, что он дописал свой код и даже смог один раз выполнить его, но еще не подвергал тестированию?

Я работал с группами, имевшими разные представления о терминах «выполнено» и «готово». В одной группе использовались термины «сделано» и «совсем сделано». У профессиональных разработчиков есть только одно определение: выполнено – значит выполнено. Сделано – значит, что весь код написан, все тесты пройдены, служба контроля качества и ключевые участники приняли результат. Сделано.

Но как добиться такого уровня выполнения, не снижая темпа перехода между итерациями? Нужно создать набор автоматизированных тестов, прохождение которых означает выполнение всех перечисленных условий! Если приемочные тесты вашей подсистемы проходят успешно, значит, работа выполнена.

Профессиональные разработчики расширяют определение требований до автоматизированных приемочных тестов. Они общаются с ключевыми участниками и специалистами по контролю качества, стремясь к тому, чтобы автоматизированные тесты полностью отражали определение «выполнения».

Сэм: «Так, еще нужно организовать резервное копирование журнальных файлов».

Пола: «С какой частотой?»

Сэм: «Ежедневно».

Пола: «Понятно. И где будут храниться резервные копии?»

Сэм: «В смысле?»

Пола: «Наверное, они должны сохраняться в определенном подкаталоге?»

Сэм: «Да, пожалуй».

Пола: «И как он будет называться?»

Сэм: «Может, backup?»

Том(тестер): «Погодите, backup – слишком общее название. Что именно будет храниться в этом каталоге?»

Сэм: «Резервные копии».

Том: «Резервные копии чего?»

Сэм: «Журнальных файлов».

Пола: «Но ведь журнальный файл всего один?»

Сэм: «Нет, их много. По одному на каждый день».

Том: «То есть у нас будет один активный журнал и много резервных копий?»

Сэм: «Конечно».

Пола: «О! А я думала, копии будут постоянно замещаться».

Сэм: «Нет, заказчик хочет, чтобы они хранились неограниченно долго».

Пола: «Для меня это новость. Хорошо, что вовремя разобрались».

Том: «Имя подкаталога должно сообщать, что именно в нем хранится».

Сэм: «Там будут храниться старые неактивные журналы».

Том: «Тогда мы назовем его old_inactive_logs».

Сэм: «Отлично».

Том: «И когда будет создаваться этот каталог?»

Сэм: «В смысле?»

Пола: «Каталог будет создаваться при запуске системы, но только в том случае, если он не существует».

Том: «Понятно, это наш первый тест. Я запускаю систему и проверяю, создан ли каталог old_inactive_logs. Затем я добавляю файл в этот каталог, завершаю работу, снова запускаю систему и проверяю, что каталог и файл находятся на положенном месте».

Пола: «На выполнение этого теста уйдет много времени. Инициализация системы уже занимает около 20 секунд, и время только растет. К тому же я не хочу собирать систему заново при каждом запуске приемочных тестов».

Том: «Что ты предлагаешь?»

Пола: «Создадим класс SystemStarter. Основная программа будет загружать его с группой объектов StartupCommand, построенных на базе паттерна «Команда». Затем во время запуска системы SystemStarterпросто приказывает всем объектам StartupCommandвыполнить свои команды. Один из этих объектов StartupCommandсоздает старый каталог old_inactive_logs, но только в том случае, если он не существует».

Том: «Ладно, тогда мне остается только протестировать этого потомка StartupCommand. Я напишу для этого простой тест FitNesse».

(Том идет к доске.)

«Первая часть будет выглядеть примерно так»:

given the command LogFileDirectoryStartupCommand

given that the old_inactive_logs directory does not exist

when the command is executed

then the old_inactive_logs directory should exist and it should be empty

«А вторая часть будет примерно такой»:

given the command LogFileDirectoryStartupCommand

given that the old_inactive_logs directory exists and that it contains a file named x

When the command is executed

Then the old_inactive_logs directory should still exist and it should still contain a file named x

Пола: «Да, этого должно хватить».

Сэм: «А это все действительно необходимо?»

Пола: «Сэм, какое из этих двух утверждений недостаточно важно для проверки?»

Сэм: «Просто я хочу сказать, что для написания всех этих тестов потребуется немало лишней работы».

Том: «Да, но не больше, чем для написания плана ручного тестирования. И намного меньше, чем для многократного выполнения тестов вручную».