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

• У вас была возможность проверить стабильность работы вашего продукта? Для выявления утечек памяти и других проблем со стабильностью критически важно проводить тесты, которые выполняются часами и сутками. Их редко запускают в дневное время, потому что они отнимают время и ресурсы. Зато можно автоматически выполнять нагрузочное тестирование в ночное время и по выходным. С 6 вечера пятницы до 6 утра понедельника у вас есть 60 часов, которые можно занять тестированием.

• Удается ли вам получить доступ к среде для тестирования производительности в удобное для вас время? Мне приходилось видеть, как команды ругаются одна с другой, выбивая себе доступ к среде для тестирования производительности. Мало кому удается получить в достаточном количестве удобное время для тестирования в рабочие часы, хотя по окончании рабочего дня серверы практически простаивают. В то же время серверы и сеть не так сильно загружены ночью и по выходным. Это идеальное время для выполнения тестов на производительность и получения надежных результатов.

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

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

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

Нил Форд

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

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

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

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

Думайте состояниями

Никлас Нильссон

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

«У нас абсолютно, ну совершенно абсолютно закончились запасы молока».

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

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