Современный рабочий инструментарий разработчика представляет собой с десяток самых разных приложений: IDE, тестовая система, различные фреймворки, системы контроля версий и контейнеризации, офисные приложения и многое другое.

И зачастую мы, сами того не замечая, тратим драгоценное время на перенос данных из одной рабочей системы в другую. Но почему бы нам не заняться оптимизацией рабочего процесса, пусть даже в мелочах? Пять минут, умноженные на 5 раз в день, дадут нам в сумме более одного рабочего дня в месяц времени, которое можно потратить куда полезнее, чем на выполнение рутинной работы. Так мы пришли к созданию расширения для Visual Studio, позволяющего нам автоматизировать процесс создания автотестов в нашей системе Test IT.

Продолжая историю про вебхуки и то, как они помогают связывать множество сервисов при работе, представляем вашему вниманию наш рассказ о создании расширения для нашей рабочей IDE – Visual Studio. Добро пожаловать под кат!

Эта статья — гостевая публикация от ребят из Test IT

Чат-бот, рассматриваемый в предыдущей статье, конечно, хорош, но он пока служит нам только для получения информации о текущем статусе автотестов. А если настроить более плотную интеграцию с системой Test IT, то мы сможем разворачивать список тестов текущего проекта на портале автоматически, без необходимости добавлять их вручную.

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

Так мы пришли к созданию расширения для Visual Studio, и сейчас расскажем немного о том, как мы его сделали.

Техническая сторона

Разрабатывать расширение мы будем, естественно, в самой Visual Studio. Ведь никто не знает про IDE столько, сколько сама IDE. Для начала убедимся в том, что в Visual Studio установлены все необходимые для создания расширений компоненты. Находим и запускаем Visual Studio Installer и проверяем модуль «Разработка расширений Visual Studio»:



Одной галочки нам вполне хватит, чтобы установить все необходимые библиотеки для работы. В сведениях об установке по разработке расширений Visual Studio должна быть примерно следующая ситуация:



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

Развернём новое расширение, найдя список доступных решений по фразе «VSIX» и выбрав VSIX Project (язык, разумеется, C#):



После разворачивания нас встречает, на первый взгляд, несложная архитектура шаблона расширения:



В данном примере source.extension.vsixmanifest является обычным манифестом, в котором прописаны основные свойства расширения, такие как имя продукта, автор, версия, описание, иконка расширения, целевая версия IDE и многие другие. К слову, именно эти свойства просматриваются как в магазине расширений, так и установщиком расширений Visual Studio.

VSIXProject3Package.cs (маска: {ProjectName}Package.cs), в свою очередь, является классом-инициализатором, регистрирующим все имеющиеся команды и схему ресурсов. С командами мы сейчас и познакомимся.

Создадим новую команду, которая откроет нам WPF-окно с параметрами расширения: нам необходимо где-то хранить данные о целевом проекте, о местонахождении и названии его сборки, о подключении к серверу и прочую информацию.

Ищем новый элемент, называемый вполне логично Command.



Многие могут задаться вопросом: почему же мы используем Command, когда под описание задачи, если верить названию, нам подходят элементы Async Tool Window и Tool Window? Всё довольно просто: эти два элемента при создании развернут нам файл разметки на xaml, cs-файл с аналогичным названием, а также команду. Всё бы ничего, вроде нам это и надо, но в данном случае Tool Window (неважно, асинхронный ли он) разворачивает шаблон окна, интегрируемого в саму Visual Studio. На выходе мы получим одно из окон, по-умолчанию развёрнутое вместо окна Debug. Разумеется, всё это настраивается, но нам необходимо стороннее окно. Именно поэтому мы не используем Tool Window, а добавим обычное WPF-окно.

Думаю, подробности создания нового окна со стандартными элементами можно опустить, так как это скучно, неинтересно и слабо соотносится с названием статьи. Единственная рекомендация, которую здесь можно оставить: Visual Studio при добавлении нового элемента не покажет вам в списке вариантов окно WPF, поэтому самый быстрый и простой вариант заключается в создании такого окна отдельно от проекта расширения и его последующем переносе в текущий проект (не забудьте исправить пространство имён).



Итак, после создания новой команды, которую мы назвали как OpenSettingsCommand, легендарная кодогенерация студии создаёт нам класс команды и файл формата vsct, хранящий в себе как разметку нашего расширения, так и сопоставление команд и вызывающих их кнопок. Разметку крайне желательно переписать на собственную реализацию: созданная автоматически, она разместит ваши элементы в меню «Расширения». В данном случае мы переписали эту разметку, создав группу из двух команд и поместив её прямо на панель инструментов. Пример команды и разметки можно найти у нас в репозитории.

В созданном классе мы можем заметить метод Execute, с которого всё и начинается при вызове данной команды. Собственно, именно здесь мы и пропишем инициализацию нового WPF-окна.

EnvDTE

И мы плавно подошли к использованию Visual Studio SDK, а именно – библиотеке EnvDTE. Данная COM библиотека позволяет нам работать с объектами и элементами Visual Studio: получать список активных решений и проектов, работать с подсветкой синтаксиса, активными окнами, читать код проектов и многое другое. На самом деле, если погрузиться в документацию данной библиотеки, то можно обнаружить для себя довольно много полезных функций. В данном примере мы используем её именно для получения списка проектов в активном решении.

Несмотря на небольшую базу кода в свободном доступе, нам хватит всего несколько строк кода, чтобы получить список проектов в активном решении:

ThreadHelper.ThrowIfNotOnUIThread();
var activeVS = (DTE)Microsoft.VisualStudio.Shell.ServiceProvider.GlobalProvider.GetService(typeof(DTE))
 ?? throw new InvalidOperationException("DTE not found");
var activeProjects = new List<Project>();
activeProjects.AddRange(activeVS.Solution.Projects.Cast<Project>());
//вот и всё, activeProjects теперь хранит в себе список проектов в активном решении

Вот так легко и непринуждённо мы можем собрать детальную информацию обо всех активных проектах.

Возьмём с этого списка имена проектов (свойство Name) и пути до csproj-файлов (внезапно, FullName): этого нам вполне хватит, чтобы спросить у пользователя нужный проект из списка возможных и сопоставить ему каталог для поиска сборок.

Следующим шагом будет подключение библиотеки, в задачи которой входит анализ сборки, сбор автотестов и их публикация на портале Test IT. Подробности создания библиотеки мы опустим, но приведём интересный класс, который умеет получать список автотестов из загруженной сборки:

public class AutotestsService
    {
        public IList<AutotestModel> GetAutotestsFromAssembly<TTestClassAttribute, TTestMethodAttribute>(Assembly assembly, Guid projectId, string repositoryLink)
            where TTestClassAttribute : Attribute
            where TTestMethodAttribute : Attribute
        {
            MethodInfo[] testMethods = GetAutotestFromAssembly<TTestClassAttribute, TTestMethodAttribute>(assembly);

            List<AutotestModel> allModels = new List<AutotestModel>();
            foreach (MethodInfo method in testMethods)
            {
                AutotestModel autotest = new AutotestModel()
                {
                    ExternalId = method.Name,
                    LinkToRepository = repositoryLink,
                    ProjectId = projectId,
                    Name = GetAutotestName(method.Name),
                    Classname = method.DeclaringType.Name,
                    Namespace = GetAutotestNamespace(method)
                };

                allModels.Add(autotest);
            }

            return allModels;
        }

        private static MethodInfo[] GetAutotestFromAssembly<TTestClassAttribute, TTestMethodAttribute>(Assembly assembly)
            where TTestClassAttribute : Attribute
            where TTestMethodAttribute : Attribute
        {
            return assembly.GetTypes()
                .Where(c => c.IsDefined(typeof(TTestClassAttribute)))
                .SelectMany(t => t.GetMethods())
                .Where(m => m.IsDefined(typeof(TTestMethodAttribute)))
                .ToArray();
        }

        private string GetAutotestName(string autotestExternalId)
        {
            StringBuilder autotestName = new StringBuilder();

            for (int i = 0; i < autotestExternalId.Length; i++)
            {
                if (char.IsUpper(autotestExternalId[i]) && i != 0)
                    autotestName.Append(' ');
                autotestName.Append(autotestExternalId[i]);
            }

            return autotestName.ToString();
        }

        private string GetAutotestNamespace(MethodInfo testMethod)
        {
            return testMethod.DeclaringType.FullName
                .Replace($".{testMethod.DeclaringType.Name}", string.Empty);
        }
    }

Весь исходный код библиотеки всегда можно посмотреть у нас в репозитории.

Итак, вернёмся к расширению. Для запуска логики нашей библиотеки необходимо добавить новую команду, в методе Execute которой пропишем вызов библиотеки, передав ей атрибуты тестовых классов и методов, а также сохранённые параметры расширения:

var settings = Properties.Settings.Default;
var executor = new LinkExecutor();
await executor.Execute<TestClassAttribute, TestMethodAttribute>(
    settings.Domain,
    settings.SecretKey,
    settings.ProjectNameInTestIT,
    settings.RepositoryLink ?? string.Empty,
    settings.AssemblyPath,
    Logger);

Важное замечание: Logger мы прокидываем в библиотеку для возможности писать техническую информацию прямо в окно вывода сообщений Visual Studio. Библиотека не должна быть привязана только к данной IDE, нам важно оставить возможность использовать её в любой ситуации.

Результаты

В результате после разработки у нас получилось примерно такое расширение:

Запустим на отладку наше расширение. Для тех, кто никогда не работал с расширениями Visual Studio, будет немного удивительным тот факт, что при отладке расширения для Visual Studio в Visual Studio будет запускаться среда Visual Studio с установленным в него расширением Visual Studio. Звучит так же страшно, как и логично.

Откроем пример решения, содержащий проект с Unit-тестами, и опробуем наше расширение на нём. При загрузке проекта сразу можем заметить новую кнопку на панели:



Сразу возьмём секретный ключ API из личного кабинета и подготовим новый проект на нашей платформе:





Далее вернёмся к расширению. Откроем наше окно с параметрами расширения и заполним поля:



В конструктор окна мы передавали список текущих проектов, любезно предоставленным библиотекой Visual Studio SDK, а варианты «Project dll» мы подгружали после выбора проекта: сервис выполнил поиск всех dll-файлов в сборке проекта «UnitTestProject» и показал нам возможные варианты библиотек. Сохраняем настройки и запускаем основной функционал нашего расширения.

В окне вывода спустя несколько секунд мы видим следующее:



Кому интересно, как мы сделали вывод сообщений – исходный код логгера можно почитать тут.

В нашем примере было 3 Unit-теста и 3 интеграционных теста. Похоже на правду. Проверим, что там на портале:

Заключение

Сегодня мы рассмотрели основы создания расширений для Visual Studio на примере расширения для публикации списка автотестов на платформе Test IT. Возможности расширений ограничиваются лишь вашей фантазией: можно реализовать чат с командой, можно создать уведомления в случае поломки проекта на вашей ветке, можно даже, как и в наших фантазиях о Bot Framework, добавить кнопку заказа пиццы в офис.

Мечтайте, творите, экономьте время и всегда оставайтесь творческими специалистами!

Об авторе

Михаил Пироговский — .NET разработчик. Материал написан вместе с командой Test IT. В нашей группе на Facebook мы рассказываем про работу в QA, тестирование, инструменты и прочее.