Visual Studio 2015 с обновлением 1 включает в себя ряд улучшений и исправлений. В этой публикации мы сконцентрируем внимание на двух улучшениях, способных существенно повысить общую производительность разработки ПО.
Тестовое ядро Visual Studio 2015 Update 1 способно параллельно выполнять тестовые сборки, что существенно повышает производительность тестирования. По умолчанию этот режим отключен, поэтому Вам необходимо включить его.
Система параллельно выполняет тестовые сборки на указанном вами количестве ядер — вплоть до всех ядер вашего компьютера. Разумеется, при наличии единственного тестового проекта это не дает никаких преимуществ. Данное решение предназначено для проектов значительного масштаба. Оно не зависит от типа используемой тестовой платформы и работает с MSTest, NUnit 2, NUnit 3 и XUnit. Этот механизм полностью независим от поддержки параллелизма базовой платформой.
Для того чтобы включить эту функцию, Вам необходимо воспользоваться файлом runsettings, который требуется включить в Visual Studio. Простой способ создания корректного файла runsettings — использование одного из шаблонов. Обратите внимание на то, что необходимо пользоваться шаблонами версии не ниже 3.1. После установки этого элемента расширения у Вас появится три шаблона; если Ввам необходим параллелизм, то воспользуйтесь шаблоном Parallel.
Выполните следующие действия:
выберите Solution (Решение), щелкните правой кнопкой мыши и выберите Add/New item (Добавить/Создать элемент);
на экране вы увидите список, похожий на представленный ниже;
выберите Parallel; Вы увидите его экземпляр во вкладке Solution Items (Элементы решения) Вашего решения.
Это все, что нужно для того, чтобы включить параллельное выполнение тестов!
Не забудьте активировать его в меню Visual Studio Test, для чего выполните следующие действия:
(1) Перейдите в файл Select Test Settings (Выберите настройки теста) из главного меню Test/Test settings (Тест/Настройки теста).
(2) Затем выберите желаемый файл Runsettings, в данном примере я назвал его Parallel2.runsettings.
(3) Убедитесь в том, что он выбран и отмечен в том же меню.
Параметры:
Содержимое файла runsettings выглядит следующим образом:
Здесь мы можем изменить значение только одного элемента — MaxCpuCount, который определяет количество параллельно выполняемых процессов. Значение 0 указывает на то, что будет выполняться максимально возможное количество процессов, оно ограничено лишь количеством ядер компьютера. Значение 1 указывает на то, что процессы будут выполняться последовательно и активным будет только один процесс (это значение задано по умолчанию). Любые другие значения определяют максимальное количество параллельно выполняемых процессов (либо число используемых ядер вашего компьютера).
Почему мы не включаем проверку на покрытие кода?
Возможно, Вы заметили, что в описании файла Parallel указано, что проверка на покрытие кода не включено. Это значит, что при активации его настроек проверка на покрытие кода не будет осуществляться. Два других шаблона устроены таким же образом, поскольку покрытие кода не дает никаких преимуществ.
Активация проверки покрытия кода снижает производительность, поскольку проверка на покрытие кода выполняется после каждого теста и существенно увеличивает суммарное время тестирования и при этом не обеспечивает никаких полезных результатов.
Отключение активации покрытия кода не означает, что Вы не можете выполнить его из Team Explorer. Напротив, Вы можете сделать это! Как ни странно, результаты выполнения этой проверки на покрытие кода не используются в Test Explorer. В двух других шаблонах активируется лишь фоновое выполнение проверки на покрытие кода, результаты которого сохраняются в файле, размещаемом в папке Test Results.
Этот файл не дает вам никаких преимуществ в Visual Studio, однако полезен в случае, если Вы хотите использовать данные проверки на покрытие кода в другой программе, например, NDepend.
Одно из преимуществ этого раздела заключается в том, что он не только включает фоновое выполнение проверки на покрытие кода, но и настраивает фильтрацию данных проверки на покрытие кода, которая может быть полезной для Вас. Эти фильтры также действуют при выполнении анализа покрытия кода из выбранных тестов («Analyze code coverage from selected tests») в Test Explorer.
В статье, ссылка на которую приведена выше, содержится набор настроек для проверки на покрытие кода. Вместо них воспользуйтесь шаблоном CompleteRunSettings, который включает в себя как эти, так и другие настройки. XML, приведенный в указанной статье, неактуален.
В шаблоне CompleteRunsettings значение параметра MaxCpuCount равно 0; это означает, что количество параллельно выполняемых процессов будет максимально возможным.
Шаблон CoverageNoParallel почти идентичен предыдущему: он содержит в себе те же поля и значения, за исключением MaxCpuCount, значение которого равно 1. Это означает, что тесты будут выполняться последовательно.
На MSDN опубликована статья о более корректной настройке модульных тестов, однако эта публикация не содержит в себе столь же подробной информации, как вышеприведённая ссылка. Тем не менее, в этой статье описаны все поля.
Я создал простой проект для параллельного выполнения тестов. Он состоит из четырех тестовых проектов, в каждом из которых содержится по одному тесту, выполняемому в течение 5 секунд. Вы можете скачать исходный код проекта отсюда и выполнить эти тесты самостоятельно.
(1) Выполнение тестов без каких-либо настроек. В этом случае тесты выполняются последовательно, и время выполнения составляет 26 секунд. Каждый тест выполняется в течение 5 секунд плюс задержка, составляющая 6 секунд.
(2) Выполнение тестов с помощью CodeCoverageNoParallel происходит так же, как при использовании старого файла runsettings. Помимо тестов выполняется проверка на покрытие кода, но без параллелизма. Суммарное время возрастает до 31 секунды.
(3) При использовании полного набора настроек, включающего в себя CodeCoverage и Parallel, время выполнения тестов уменьшается до 18 секунд.
(4) При использовании только Parallel без проверки на покрытие кода время выполнения тестов сокращается до 12 секунд.
Таким образом, вариант (4) более чем вдвое повышает производительность по сравнению с вариантом (1). Это хороший результат!
Компьютер, на котором выполнялись эти тесты, был оснащен 8 ядрами, однако другие программы не давали возможности задействовать все эти ядра для тестирования. Рост производительности тестирования не кратен числу ядер компьютера, однако двукратный прирост является хорошим и весьма ощутимым достижением в повседневной работе.
Параллельное выполнение на сервере сборки
Работает ли описанная схема на сервере сборки? Да: в определении сборки Вы можете указать, какой файл runsettingfile будет использоваться при выполнении сервера сборки. Но задайте себе другой вопрос: действительно ли Вам это нужно? Ответ зависит от того, сколькими серверами сборки Вы пользуетесь, каковы их настройки и сколько проверок и фиксаций Вы выполняете, т.е. от нагрузки на серверы сборки. Обычно на каждом ядре компьютера выполняется по одному агенту сборки. Если в течение дня Вы пользуетесь большим количеством определений сборки и постоянно выполняете фиксации и проверки, то нагрузка на агентов сборки будет велика и дополнительное параллельное выполнение тестов не вызовет существенного эффекта, поскольку тесты «лишат» другие сборки доступа к ядрам компьютера. Кроме того, могут появиться и дополнительные расходы, которые нейтрализуют рост производительности.
С другой стороны, если компьютер, используемый для сборки, не сильно загружен и количество фиксаций невелико, то почему бы не увеличить его производительность за счет параллельного выполнения тестов?
Существуют и другие способы параллельного выполнения тестов, один из которых описан в этой статье.
Выполнение тестов с учетом контекста — одна из новых возможностей Update 1. Новый Test Explorer тестирует только те сборки, в коде которых он обнаруживает изменения.
Это означает, что если вы работаете с фрагментом кода в определённом модуле Вашей системы, при этом код используется в нескольких модулях. При внесении Вами изменений в одном из модулей в сборке участвует только код, который Вы модифицировали. Это обычная добавочная сборка, которая используется по умолчанию. Новизна заключается в том, что при тестировании выполняются только тесты, проверяющие измененный код. Очевидно, что это существенно повышает производительность тестирования крупных систем.
Для того чтобы воспользоваться этой функцией, вам необходимо активировать пункт «Run tests after build» («Выполнять тесты после сборки»).
Это можно сделать в Test Explorer (1) или в главном меню Test/Test Settings/Run Tests after Build (Тест/Настройки теста/Выполнять тесты после сборки) (2).
Результаты представлены на следующем снимке экрана:
(1) Активируйте «Run tests after build» («Выполнять тесты после сборки»).
(2) Внесите изменения в код
(3) Выберите Build (Выполнить сборку) или воспользуйтесь соответствующим сочетанием клавиш
(4) Будут выполнены только необходимые тесты, а остальные тесты будут отображены приглушенным зеленым цветом. В предыдущий раз они выполнялись и отображались зеленым цветом, однако в этот раз они не выполняются, поскольку проверяемый ими код не изменился.
Этот процесс поможет Вам существенно повысить производительность при тестировании крупных проектов и ускорить переход к редактированию кода после тестирования очередной сборки. Согласитесь, что это важное преимущество для разработчика!
Параллельное выполнение тестов
Тестовое ядро Visual Studio 2015 Update 1 способно параллельно выполнять тестовые сборки, что существенно повышает производительность тестирования. По умолчанию этот режим отключен, поэтому Вам необходимо включить его.
Система параллельно выполняет тестовые сборки на указанном вами количестве ядер — вплоть до всех ядер вашего компьютера. Разумеется, при наличии единственного тестового проекта это не дает никаких преимуществ. Данное решение предназначено для проектов значительного масштаба. Оно не зависит от типа используемой тестовой платформы и работает с MSTest, NUnit 2, NUnit 3 и XUnit. Этот механизм полностью независим от поддержки параллелизма базовой платформой.
Для того чтобы включить эту функцию, Вам необходимо воспользоваться файлом runsettings, который требуется включить в Visual Studio. Простой способ создания корректного файла runsettings — использование одного из шаблонов. Обратите внимание на то, что необходимо пользоваться шаблонами версии не ниже 3.1. После установки этого элемента расширения у Вас появится три шаблона; если Ввам необходим параллелизм, то воспользуйтесь шаблоном Parallel.
Выполните следующие действия:
выберите Solution (Решение), щелкните правой кнопкой мыши и выберите Add/New item (Добавить/Создать элемент);
на экране вы увидите список, похожий на представленный ниже;
выберите Parallel; Вы увидите его экземпляр во вкладке Solution Items (Элементы решения) Вашего решения.
Это все, что нужно для того, чтобы включить параллельное выполнение тестов!
Не забудьте активировать его в меню Visual Studio Test, для чего выполните следующие действия:
(1) Перейдите в файл Select Test Settings (Выберите настройки теста) из главного меню Test/Test settings (Тест/Настройки теста).
(2) Затем выберите желаемый файл Runsettings, в данном примере я назвал его Parallel2.runsettings.
(3) Убедитесь в том, что он выбран и отмечен в том же меню.
Параметры:
Содержимое файла runsettings выглядит следующим образом:
Здесь мы можем изменить значение только одного элемента — MaxCpuCount, который определяет количество параллельно выполняемых процессов. Значение 0 указывает на то, что будет выполняться максимально возможное количество процессов, оно ограничено лишь количеством ядер компьютера. Значение 1 указывает на то, что процессы будут выполняться последовательно и активным будет только один процесс (это значение задано по умолчанию). Любые другие значения определяют максимальное количество параллельно выполняемых процессов (либо число используемых ядер вашего компьютера).
Почему мы не включаем проверку на покрытие кода?
Возможно, Вы заметили, что в описании файла Parallel указано, что проверка на покрытие кода не включено. Это значит, что при активации его настроек проверка на покрытие кода не будет осуществляться. Два других шаблона устроены таким же образом, поскольку покрытие кода не дает никаких преимуществ.
Активация проверки покрытия кода снижает производительность, поскольку проверка на покрытие кода выполняется после каждого теста и существенно увеличивает суммарное время тестирования и при этом не обеспечивает никаких полезных результатов.
Отключение активации покрытия кода не означает, что Вы не можете выполнить его из Team Explorer. Напротив, Вы можете сделать это! Как ни странно, результаты выполнения этой проверки на покрытие кода не используются в Test Explorer. В двух других шаблонах активируется лишь фоновое выполнение проверки на покрытие кода, результаты которого сохраняются в файле, размещаемом в папке Test Results.
Этот файл не дает вам никаких преимуществ в Visual Studio, однако полезен в случае, если Вы хотите использовать данные проверки на покрытие кода в другой программе, например, NDepend.
Одно из преимуществ этого раздела заключается в том, что он не только включает фоновое выполнение проверки на покрытие кода, но и настраивает фильтрацию данных проверки на покрытие кода, которая может быть полезной для Вас. Эти фильтры также действуют при выполнении анализа покрытия кода из выбранных тестов («Analyze code coverage from selected tests») в Test Explorer.
В статье, ссылка на которую приведена выше, содержится набор настроек для проверки на покрытие кода. Вместо них воспользуйтесь шаблоном CompleteRunSettings, который включает в себя как эти, так и другие настройки. XML, приведенный в указанной статье, неактуален.
В шаблоне CompleteRunsettings значение параметра MaxCpuCount равно 0; это означает, что количество параллельно выполняемых процессов будет максимально возможным.
Шаблон CoverageNoParallel почти идентичен предыдущему: он содержит в себе те же поля и значения, за исключением MaxCpuCount, значение которого равно 1. Это означает, что тесты будут выполняться последовательно.
На MSDN опубликована статья о более корректной настройке модульных тестов, однако эта публикация не содержит в себе столь же подробной информации, как вышеприведённая ссылка. Тем не менее, в этой статье описаны все поля.
Тестовый проект для параллельного выполнения
Я создал простой проект для параллельного выполнения тестов. Он состоит из четырех тестовых проектов, в каждом из которых содержится по одному тесту, выполняемому в течение 5 секунд. Вы можете скачать исходный код проекта отсюда и выполнить эти тесты самостоятельно.
(1) Выполнение тестов без каких-либо настроек. В этом случае тесты выполняются последовательно, и время выполнения составляет 26 секунд. Каждый тест выполняется в течение 5 секунд плюс задержка, составляющая 6 секунд.
(2) Выполнение тестов с помощью CodeCoverageNoParallel происходит так же, как при использовании старого файла runsettings. Помимо тестов выполняется проверка на покрытие кода, но без параллелизма. Суммарное время возрастает до 31 секунды.
(3) При использовании полного набора настроек, включающего в себя CodeCoverage и Parallel, время выполнения тестов уменьшается до 18 секунд.
(4) При использовании только Parallel без проверки на покрытие кода время выполнения тестов сокращается до 12 секунд.
Таким образом, вариант (4) более чем вдвое повышает производительность по сравнению с вариантом (1). Это хороший результат!
Компьютер, на котором выполнялись эти тесты, был оснащен 8 ядрами, однако другие программы не давали возможности задействовать все эти ядра для тестирования. Рост производительности тестирования не кратен числу ядер компьютера, однако двукратный прирост является хорошим и весьма ощутимым достижением в повседневной работе.
Параллельное выполнение на сервере сборки
Работает ли описанная схема на сервере сборки? Да: в определении сборки Вы можете указать, какой файл runsettingfile будет использоваться при выполнении сервера сборки. Но задайте себе другой вопрос: действительно ли Вам это нужно? Ответ зависит от того, сколькими серверами сборки Вы пользуетесь, каковы их настройки и сколько проверок и фиксаций Вы выполняете, т.е. от нагрузки на серверы сборки. Обычно на каждом ядре компьютера выполняется по одному агенту сборки. Если в течение дня Вы пользуетесь большим количеством определений сборки и постоянно выполняете фиксации и проверки, то нагрузка на агентов сборки будет велика и дополнительное параллельное выполнение тестов не вызовет существенного эффекта, поскольку тесты «лишат» другие сборки доступа к ядрам компьютера. Кроме того, могут появиться и дополнительные расходы, которые нейтрализуют рост производительности.
С другой стороны, если компьютер, используемый для сборки, не сильно загружен и количество фиксаций невелико, то почему бы не увеличить его производительность за счет параллельного выполнения тестов?
Существуют и другие способы параллельного выполнения тестов, один из которых описан в этой статье.
Выполнение тестов с учетом контекста
Выполнение тестов с учетом контекста — одна из новых возможностей Update 1. Новый Test Explorer тестирует только те сборки, в коде которых он обнаруживает изменения.
Это означает, что если вы работаете с фрагментом кода в определённом модуле Вашей системы, при этом код используется в нескольких модулях. При внесении Вами изменений в одном из модулей в сборке участвует только код, который Вы модифицировали. Это обычная добавочная сборка, которая используется по умолчанию. Новизна заключается в том, что при тестировании выполняются только тесты, проверяющие измененный код. Очевидно, что это существенно повышает производительность тестирования крупных систем.
Для того чтобы воспользоваться этой функцией, вам необходимо активировать пункт «Run tests after build» («Выполнять тесты после сборки»).
Это можно сделать в Test Explorer (1) или в главном меню Test/Test Settings/Run Tests after Build (Тест/Настройки теста/Выполнять тесты после сборки) (2).
Результаты представлены на следующем снимке экрана:
(1) Активируйте «Run tests after build» («Выполнять тесты после сборки»).
(2) Внесите изменения в код
(3) Выберите Build (Выполнить сборку) или воспользуйтесь соответствующим сочетанием клавиш
(4) Будут выполнены только необходимые тесты, а остальные тесты будут отображены приглушенным зеленым цветом. В предыдущий раз они выполнялись и отображались зеленым цветом, однако в этот раз они не выполняются, поскольку проверяемый ими код не изменился.
Этот процесс поможет Вам существенно повысить производительность при тестировании крупных проектов и ускорить переход к редактированию кода после тестирования очередной сборки. Согласитесь, что это важное преимущество для разработчика!
