# Тестируйте по ночам и в выходные

(В оригинале - Test While You Sleep (and over Weekends))

Расслабьтесь. Я не имею в виду удаленный центр разработки, выход на работу в выходные или введение ночных смен. Вместо этого я хочу обратить внимание на то, сколько вычислительной мощности имеется в нашем распоряжении. Особенно о том, насколько мы не используем его для того, чтобы облегчить себе жизнь. Вам все время не хватает вычислительной мощности в течение дня? Если это так, то что делают ваши тестовые сервера в нерабочее время? Чаще всего, они простаивают, как по ночам, так и по выходным. И вы можете это использовать.

* *Приходилось ли вам помещать изменение в систему контроля версий без выполнения полного набора тестов?* Одной из причин, почему программисты не запускают тесты перед помещением, является долгое время выполнение полного набора тестов. Когда дедлайн поджимает, люди начинают искать короткие пути. Одно из решений – разбить тесты на две группы. Маленькая, при этом обязательная группа тестов, быстро выполняющаяся, поможет убедиться в том, что перед каждым коммитом проект все еще как-то работает. И большая (при этом включающая в себя и первую маленькую группу тоже, на всякий случай), запускающаяся ночью автоматически и выдающая полный отчет к утру следующего дня.
* *У вас достаточно возможностей протестировать стабильность вашего продукта?* Долгоисполняющиеся тесты важны для обнаружения утечек памяти и других проблем стабильности. Они редко запускаются в рабочее время из-за ограниченности ресурсов. Вы можете запускать эти тесты в пятницу вечером, и до утра в понедельник тесты смогут проработать 60 часов без перерыва.
* *Вам достаточно времени для проведения тестов производительности?* Я видел множество команд, сражающихся за доступ к оборудованию для тестирования производительности. В большинстве случаев командам не хватало времени для работы на нем в течении дня, при этом оборудование простаивало в остальное время. И сервера, и сеть менее всего нагружены по ночам и выходным, и в это время лучше всего проводить тесты производительности.
* *Слишком много комбинаций для тестирования?* Во многих случаях продукт должен работать на нескольких платформах, например, на 32 и 64-х битных Windows, Linux и Solaris, или же на различных версиях одной операционной системы. При этом тестируемое приложение может использовать множество различных транспортных механизмов и протоколов (HTTP, AMQP, SOAP, CORBA и т.п.). Тестирование всех комбинаций вручную очень затратно по времени и чаще всего делается ближе к дате выпуска из-за нехватки ресурсов. И это может быть слишком поздно. Автоматизированные тесты, запускаемые по ночам или на выходных, могут протестировать все комбинации более тщательно.

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

Автор оригинала - [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/ru/thing_81.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.