Мне показалось, что использование Ordered Tests очень удобно подходит для реализации тестов верхнего уровня, которые просто представляют набор из вызова базовых “кирпичиков”. По привычке, Oredered Test были помещены в одельную папку внутри проекта.

Запуск тестов из IDE проходит без проблем, а вот если “автоматизировать” test case, и попробовать его прогнать через Microsoft Test and Lab Management (MTLM) в виртуальной среде, то возникает проблема – запуск завершается с ошибкой “Cannot find the test ‘<имя_теста>’ with storage ‘..\bin\debug\<имя_сборки_с_тестами>.dll’.”.

На первый взгляд, меня смутил относительный путь, проставленный IDE. Но ведь там то всё работает, даже если запускать “Release” конфигурацию! Ситуация прояснилась, при внимательном рассмотрении папки, которую готовит для запуска тестов IDE и папки с результатами сборки продукта при помощи Team Build, которую использует MTLM.

Собака порылась в местолоположении файла .orderedtest – IDE его кладёт рялдом с бинарниками перед запуском, а MTLM, нет. Это, безусловно, баг (уж не знаю, как его правильно решать – скорее всего, на стороне MTLM), так как поведение IDE отличается от поведения MTLM, если файл .orderedtest лежит не в корне проекта, а в подпапке, и, соответсвенно, копируется в OutDir при сборке с соблюдением иерархии.

Пошёл писать баг коллегам из Микрософта.

delete this;

this->GetClient()->SetEntity(this->GetClient()->GetLastEntityIdx(), NULL);

Ну как, цепляет?

Когда мы добавили восьмой Hyper-V хост, весь наш 4-х мегабитный канал стал накрываться. SCVMM начал неприрывно обновлять информацию о виртуалках. Совместно со сужбой технической поддержки Microsoft, мы достаточно быстро изменили интервалы обновления. Теперь, если не лезть в Hyper-V напрямую, как-то оно дышит. В настоящее время, активно решаем с разработчиками SCVMM – как убедить его обслуживать 20 Hyper-V хостов, которые нам необходимы. Кстати, поддержка удалённых офисов была заявлена одной из 3-х ключевых фич SCVMM 2008 R2.

Продолжение следует.

• Инструменты Windows Azure для Microsoft Visual Studio 1.2 (июнь 2010)

Сейчас мы дотачиваем настройку Test and Lab Management и очень надеюсь, что скоро смогу порадовать всех какими-то полезными техническими советами по настроке самого TFS и TFS Build.

1. Прямо с этой минуты, в Azure можно пользоваться .Net Framework 4.0
2. Доступна новая версия Aure Tools для Visual Studio. Не скрою, я уже успел с ней поиграть – выглядит очень впечатляюще. Чего стоит только возможность вынимать из облака IntelliTrace! Ставьте, не пожалеете.

Во-первых, не перестаю восторгаться иерархическими WI и gated check-in. Правда, для того, чтобы обновится до CMMI v5 и сохранить нашу кастомизацию, немного пришлось повозиться с копированием значений из “Steps to reroduce” в “Repro steps”. Без этого было не обойтись, так была нужна поддержка Test and Lab Management.

Во-вторых, всплыли две проблемы:

1. Если на машине стоит .Net 4.0 (что, естественно, необходимо для сборки под TFS 2010), то ломается компиляция VS 2008 Workflow Fundation проектов, которые используют дженерики. Открыл кейз на эту тему. Команда Workflow проблему подтвердила, но, говорит, чинить боимся – очень уж опасно. Продолжаю объяснять, что переводить старые проекты на VS 2010 не вариант.
2. В нашей хитрой топологии сети возникла проблема с медленным поднятием Test Runner-а. После клика на “Run” приходится ждать две-три минуты, потом всё быстро. Разработчики сказали, что нормальное время должно быть не более 5-ти секунд. Завёл баг 559765 на эту тему. Разбираемся. Желающим могу рассказать о том, как включить трассировку mtlm.exe.

Продолжаю работать над новыми возможностями для TFS build. Доделаю – расскажу.

По традиции, пркольный текст задачки для 1-4 класса (просьба извинить преподавателей за орфографические ошибки – как правило, они составляют тексты задач ночью):

Немного разберу завалы на работе и обязательно расскажу о том, как у нас идут дела с TFS 2010.

А пока посмотрите ролик, который вложили коллеги из Microsoft:

Это видео также доступно тут http://www.microsoft.com/visualstudio/ru-ru/events/#quest.

Готовлю доклад об автоматизации сборки и её новых возможностях.

Хоть это и происходит редко, последствия крайне неприятны, особенно в том случае, если Вы используете непрерывную сборку. Представьте – разработчик собирает в IDE проект, и со спокойной душой кладёт изменения в систему контроля версий. Далее происходит сборка продукта и она ломается. Разработчик в недоумении. Все поледующие изменения, внесённые другими членами команды тоже приводят к сломанной сборке и проблема растёт как снежный ком (ну, конечно, если у Вас нет TFS 2010 и gated chek-in).

В среднестатистической команде, далеко не каждый разработчик в состоянии разобраться с подобной проблемой.

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

В принцепе, это можно сделать из командной строки, натравив MSBuild на файл сборки TFSBuild.proj. На первый взгляд, задача выглядит не сложной. Но это только в том случае, если структура папок в системе контроля версий у Вас выбрана по-умолчанию. Если же, например, в одном проекте Вы храните разные ветки продукта, делаете ветвления (что очевидно для грамотной разработки проекта), то файл TFSBuild.proj, с большой долей вероятности, лежит в другом месте. В моём случае, есть следующая структура проектов:

Проблема заключается в том, что умолчательные пути для результата сборки и тестов будут располагаться по вот такому пути “..\..\Binaries” и “..\..\TestResults” соответсвенно. Это ещё половина беды, так как самое страшное в этом случае то, что результат сборки будет просто выше по иерархии. Это не красиво, но не смертельно. Хуже другое – запуск коммандной строки

MSBuild TFSBuild.proj

в папке Build, где у меня лежит файл проекта сборки, просто сломается. Дело в том, что MSBuild будет искать solution файл в папке “..\..\Sources”. В моём случае не обойтись без параметров:

MSBuild TFSBuild.proj –p:SolutionRoot=..\

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

<PropertyGroup>

  <!-- Set default paths for desktop build -->

  <BuildDefinition Condition=" '$(IsDesktopBuild)' != 'false' and '$(BuildDefinition)' == '' ">DesktopBuild</BuildDefinition>

  <SolutionRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(SolutionRoot)' == '' ">$(MSBuildProjectDirectory)\..\</SolutionRoot>

  <DesktopBuildOutputRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(DesktopBuildOutputRoot)' == '' ">$(MSBuildProjectDirectory)\..\TfsDesktopBuild</DesktopBuildOutputRoot>

  <BinariesRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(BinariesRoot)' == '' ">$(DesktopBuildOutputRoot)\Binaries</BinariesRoot>

  <TestResultsRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(TestResultsRoot)' == '' ">$(DesktopBuildOutputRoot)\TestResults</TestResultsRoot>

</PropertyGroup>

Обращаю внимание, что сделать это надо до строки импорта TFS build проекта:

<!-- Do not edit this --><Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" /><ProjectExtensions>

В своей реализации я оставил возможность для эстетов таки переопредилить и мои умолчания

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