97 этюдов для программистов. Опыт ведущих экспертов

• Не слишком ли много у вас разных конфигураций, чтобы тестировать их вручную? Часто продукт рассчитан на работу на нескольких платформах. Например, 32-разрядные и 64-разрядные версии для Linux, Solaris и Windows или просто для нескольких версий одной операционной системы. Дело осложняется еще и тем, что современные приложения допускают применение множества транспортных механизмов и протоколов (HTTP, AMQP, SOAP, CORBA и т. д.). Проверка всех возможных сочетаний требует очень много времени и чаще всего выполняется ближе к выпуску продукта в силу ограниченности ресурсов. Увы, некоторые ужасные ошибки обнаруживаются лишь на этой стадии, когда уже слишком поздно.

Запуск автоматизированных тестов по ночам или на выходных позволит чаще проверять все эти сочетания. Стоит чуть пораскинуть мозгами и приложить некоторые познания в написании сценариев, и вы сможете создать с помощью планировщика cron несколько заданий, которые будут запускать тесты по ночам и на выходных. Существует также множество полезных инструментов для тестирования. В некоторых организациях созданы даже серверные сетки, распределяющие серверы между разными отделами и командами с целью более эффективного использования ресурсов. Если в вашей организации есть такие средства, вы можете отдать тесты на выполнение в ночное время или на выходных.

Тестирование — это инженерная строгость в разработке программного обеспечения Нил Форд

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

В сравнении с «реальной» инженерией разработка программ находится примерно на том уровне, где были строители мостов в далеком прошлом. В те дни стандартный подход был такой: сначала построить мост, а потом пустить по нему тяжелую повозку. Если выдержит, значит, мост хороший. Если нет — что ж, возвращаемся к чертежной доске. За последние несколько тысяч лет инженеры развили математику и физику до такой степени, что отпала необходимость строить объект, чтобы понять, как он работает, — для поиска надежных решений строительство уже не требуется. Ничего подобного в программировании нет и, вероятно, не будет, потому что программное обеспечение имеет очень существенные отличия. Классическое исследование разницы между программной и обычной инженерией провел Джек Ривс (Jack Reeves) в статье «What is Software Design?»,[28] опубликованной в «C++ Journal» в 1992 году. Статья, написанная почти два десятилетия назад, и сегодня на удивление верна. Ривс в своем сравнении нарисовал мрачную картину, но в 1992 году еще не было одной вещи: серьезного и повсеместного подхода к тестированию программного обеспечения.

Тестировать «реальные» объекты тяжело, потому что, прежде чем тестировать, их нужно построить, а это отбивает охоту возводить рискованную постройку только для того, чтобы посмотреть, что из этого получится. Но в отрасли программного обеспечения «строительство» обходится смехотворно дешево. Мы создали целую экосистему инструментов, с помощью которых его легко осуществить: модульное тестирование, объекты-макеты, средства тестирования и многое другое. Другие инженеры были бы безумно рады возможности что-то построить и протестировать в реальных условиях. Мы, разработчики программного обеспечения, должны принять тестирование в качестве главного (но не единственного) механизма верификации для программ. Не нужно ждать появления своего рода «высшей математики» для программирования, потому что в нашем распоряжении уже есть инструменты, гарантирующие хорошую инженерную практику. В этом смысле у нас есть оружие против менеджеров, которые говорят нам, что «нет времени для тестирования». Строитель моста никогда не услышит от своего начальника: «Не трать время на расчет прочности этого здания — мы не укладываемся в график». Если признать, что тестирование — это реальный способ добиться воспроизводимости и качества в отрасли ПО, это позволит нам, разработчикам, отвергать доводы против тестирования как безответственные с профессиональной точки зрения.

Тестирование точно так же требует времени, как его требует и расчет прочности моста. Оба процесса служат гарантии качества конечного продукта. Разработчикам программного обеспечения пора взять на себя ответственность за то, что они производят. Одного тестирования недостаточно, но оно необходимо. Тестирование и есть инженерная строгость в разработке программного обеспечения.