Да. :)
В VS2008, когда вы создаете тестовый проект, Visual Studio также создает файл тестовых метаданных или файл vsmdi. Решение может иметь только один файл метаданных. Этот файл является манифестом всех тестов, созданных в рамках решения для всех тестовых проектов. Открыв файл метаданных, откройте редактор списка тестов - графический интерфейс для редактирования и выполнения файла.
Из редактора списка тестов вы можете создавать списки тестов [например, UnitTestList, IntegrationTestList] и назначать отдельные тесты конкретному списку тестов. По умолчанию редактор списка тестов перечисляет все тесты в списке «Все загруженные тесты» и в списке «Тесты отсутствуют в списке», чтобы помочь в назначении тестов. Используйте их, чтобы найти или назначить группы тестов спискам. Помните, что тест может принадлежать только одному списку.
Существует два способа вызвать список тестов
- Из Visual Studio каждый список может быть вызван индивидуально из редактора списка тестов.
- Из командной строки MSTest может быть вызван с определенным списком.
Один вариант удобен для разработчиков в повседневной работе, а другой - для автоматизированных процессов сборки.
Я настроил нечто подобное в последнем проекте, над которым работал.
Эта функция очень ценна *.
В идеале, мы хотели бы запускать каждый возможный тест всякий раз, когда мы модифицируем нашу кодовую базу. Это дает нам лучший ответ на наши изменения, когда мы их вносим.
Однако на практике запуск каждого теста в наборе тестов часто означает добавление времени выполнения в минутах или часах к времени сборки [в зависимости от размера базы кода и среды сборки] - что непомерно дорого для разработчика и Continuous Integration [CI ] среды, обе из которых требуют быстрого изменения, чтобы обеспечить соответствующий ответ.
Возможность задавать явные тестовые списки позволяет разработчику, среде CI и среде Final build выборочно ориентироваться на функциональность, не жертвуя контролем качества и не влияя на общую производительность.
В данном случае я работал над распределенным приложением. Мы написали собственные службы Windows для обработки входящих запросов и использовали веб-службы Amazon для хранения. Мы не хотели запускать наш набор тестов Amazon при каждой сборке, потому что
- Амазонка не всегда работала
- Мы не всегда были на связи
- Время отклика может быть измерено в сотнях миллисекунд, что в пакете тестовых запросов может легко сократить время выполнения нашего набора тестов
Однако мы хотели сохранить эти тесты, поскольку нам требовался набор для проверки поведения. Если у меня, как у разработчика, возникли сомнения по поводу нашей интеграции с Amazon, я мог бы при необходимости выполнять эти тесты из своей среды разработки. Когда пришло время продвигать Финальную сборку для QA, Cruise Control также мог выполнить эти тесты, чтобы гарантировать, что кто-то в другой функциональной области случайно не нарушит интеграцию с Amazon.
Мы поместили эти тесты Amazon в список тестов интеграции, который был доступен каждому разработчику и выполнялся на машине для сборки, когда круиз-контроль вызывался для продвижения сборки. Мы поддерживали еще один список модульных тестов, который также был доступен каждому разработчику и выполнялся для каждой сборки. Поскольку все они были в памяти [и хорошо написаны:] и выполнялись примерно столько же времени, сколько потребовалось для сборки проекта, они не влияли на отдельные операции сборки и своевременно обеспечивали отличную обратную связь с круиз-контролем. *
* = ценный == важный. «значение» - это слово дня:)