Можно ли получить отчет о модульных тестах, выполненных в сборках TFS, сгруппированных по решениям?

У нас есть несколько тысяч нативных и модульных тестов .NET. В Visual Studio 2012 я могу запустить и просмотреть результаты, сгруппированные по проекту C++/C#.

Я хотел бы получить что-то вроде этого представления, предпочтительно сгруппированного по решению (продукту), а затем по проекту (.dll), для деловых людей. Как минимум, я хотел бы, по крайней мере, чтобы количество тестов было запущено и не выполнено для каждого решения.

Есть ли правильный способ сделать это с TFS?

Я искал везде и продолжаю натыкаться на стены,

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

  • Списки .vsmdi и файлы .testsettings были прекращены в VS 2012 и TFS 2012. Раньше у нас были отдельные списки для каждого решения... теперь это просто *test*.dll

  • Планы тестирования и пользовательские отчеты SSRS кажутся совершенно бесполезными для такой степени детализации результатов тестирования (почему?). В TfsTestWarehouse почти ничего нет — достаточно для общего количества пройденных/непройденных тестов на сборку.

  • Разбор файлов TRX и создание отчетов в формате HTML лучше всего работает с такими инструментами, как trx2html, но я все еще не могу запускать тесты. по решению.

unit-testing vs-unit-testing-framework visual-studio-2012
person makhdumi    schedule 24.10.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Файлы TRX — это просто XML-файлы, их не нужно анализировать. Вы можете написать преобразование XSLT, чтобы представить данные в нужном вам формате. Хорошая особенность XSLT заключается в том, что он имеет встроенные возможности агрегирования, группировки, сортировки и т. д.

В случае, если сами файлы TRX не содержат информации о решении (что вполне вероятно), вам придется выполнить двухэтапную генерацию отчета: подготовить данные, сгенерировать отчет.

Подготовкой будет относительно простой инструмент командной строки, который будет просматривать ваши файлы sln и строить карту того, какие проекты принадлежат решениям while (поищите в Интернете, я уверен, что для этого уже есть куча сценариев).

И часть генерации будет использовать это сопоставление в качестве аргумента для преобразования и создания отчета для правильной агрегации данных.

Я знаю, это немного общий ответ, но надеюсь, что он хоть немного поможет.

person Nikita R.    schedule 31.10.2013

arrow_upward
0
arrow_downward

В итоге я решил эту проблему, добавив информацию о проекте и решении в настраиваемый атрибут сборки (т. е. в тестовую .dll) во время сборки с помощью пользовательской задачи MSBuild. Вот примерно шаги, которые я выполнил (по памяти).

Сначала я создал пользовательский атрибут:

[AttributeUsage(AttributeTargets.Assembly)]
public class ProjectAttribute: Attribute {
    public string Project { get; set; }
    public string Solution { get; set; }
    public ProjectAttribute(string project, string solution)
    {
        this.Project = project;
        this.Solution = solution;
    }
}

Этот настраиваемый атрибут был определен в сборке, на которую ссылались все проекты модульных тестов.

Затем я создал очень простую/рудиментарную встроенную задачу MSBuild, CreateProjectAttribCs, которая динамически создавала дополнительный файл C# с одной строкой. Что-то типа:

[assembly: ProjectAttribute(Project="$(ProjectName)") Solution="$(Solution)"]

Затем я добавил этот файл в группу элементов <Compile> внутри пользовательской цели MSBuild, вызванной перед компиляцией (опять же, просто по памяти):

<Target Name="CreateProjectAttribCs" BeforeTargets="Compile">
    <CreateProjectAttribCs File="ProjectAttribute.cs" />
    <ItemGroup>
        <Compile Include="ProjectAttribute.cs" />
    </ItemGroup>
</Target>
<Target Name="CleanupProjectAttribCs" AfterTargets="Compile>
    <Delete Files="ProjectAttribute.cs" />
</Target>

Для проектов C++ я добавил информацию о проекте и решении в ресурс таблицы строк, «внедренный» аналогично файлу ProjectAttrib.cs.

Одной из основных неприятностей со всем этим было то, что разработчикам приходилось добавлять этот пользовательский файл MSBuild .targets (который будет содержать пользовательские цели и ссылку на сборку), редактируя файл .csproj или .vcxproj.

Чтобы немного обойти это, я также создал собственный шаблон проекта Visual Studio для модульных тестов нашей команды, чтобы все было уже добавлено, и моим коллегам-разработчикам никогда не приходилось видеть внутренности проекта MSBuild.

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

person makhdumi    schedule 26.05.2015