Как проверить код в visual studio

Обновлено: 07.07.2024

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

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

В состав Visual Studio входит модульное тестирование.

Такое тестирование отдельных частей программы, называется unit-тестированием (модульное тестирование) .

Задача состоит в том, чтобы написать дополнительный класс с методами, который будет тестировать наши основные классы.

Как создать модули-тестирования?

Добавим новый проект в наш "Solution". Воспользуемся мастером, который входит в состав "Visual Studio". Шаблон проекта: "Unit Test Project" (Проект модульного теста). Имя проекта укажем "MyTest":

Отличие от обычно класса заключается в том, что здесь присутствуют атрибуты "TestClass" и "TestMethod":

Эти 2 атрибута навешены для того, чтобы компонент NUnit (компонент Visual Studio) , когда мы захотим запустить тесты, понял где эти тесты находятся.
В этом тестовом проекте необходимо добавить ссылку ("Add reference") на основной проект, также добавить ссылку на основной проект, используя using.

Что является пройденным и непройденным тестированием?

Если метод нормально закончил работу, значит тест считается пройденным. Если было выброшено любое исключение, то тест считается непройденным. Исключения можно выбрасывать самим. Также можно использовать методы класса "Assert".Например, у данного класса есть метод "AreEqual()". Он сравнивает то, что ожидаем получить с тем, что получилось по факту.

Обычно эти атрибуты используются при сложном тестировании. Для чего они могут быть нужны? Допустим перед началом тестирования вам нужно поместить какие-то тестовые данные в базу данных, либо какой-нибудь файл. После окончания тестирования то содержимое, которое мы добавили для этой базы или файла, нужно удалить.

Давайте напишем простой пример.

Напишем класс "Room"

Класс для тестирования:

Если мы теперь запустим тестирование, то выйдет ошибка тестирования (на скриншоте):

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

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

На связи был Алексей Гулынин, оставляйте свои комментарии, увидимся в следующих статьях.

При включении функции Live Unit Testing в решении Visual Studio она визуально описывает охват тестов и их состояние. Она также динамически выполняет тесты при каждом изменении кода и немедленно уведомляет, если изменение вызвало сбой.

Предварительные требования

Создание решения и проекта библиотеки классов

Решение — это просто контейнер для одного или нескольких проектов. Чтобы создать пустое решение, откройте Visual Studio и сделайте следующее:

Выберите Файл > Создать > Проект в меню верхнего уровня Visual Studio.

Введите решение в поле поиска шаблона и выберите шаблон Пустое решение. Присвойте проекту имя UtilityLibraries.

Завершите создание решения.

После создания решения вы создадите библиотеку классов с именем StringLibrary, которая содержит несколько методов расширения для работы со строками.

В обозревателе решений щелкните решение UtilityLibraries правой кнопкой мыши и последовательно выберите пункты Добавить > Новый проект.

Присвойте проекту имя StringLibrary.

Щелкните Создать, чтобы создать проект.

Замените весь существующий код, отображаемый в редакторе кода, следующим кодом:

StringLibrary имеет три статических метода:

StartsWithUpper возвращает true , если строка начинается с прописной буквы; в противном случае он возвращает false .

StartsWithLower возвращает true , если строка начинается со строчной буквы; в противном случае он возвращает false .

HasEmbeddedSpaces возвращает true , если строка содержит внедренный пробел; в противном случае он возвращает false .

Выберите Сборка > Сборка решения в меню верхнего уровня Visual Studio. Сборка должна выполниться успешно.

Создание тестового проекта

Следующим шагом является создание проекта модульного теста для тестирования библиотеки StringLibrary. Создайте модульные тесты, выполнив следующие действия:

В обозревателе решений щелкните решение UtilityLibraries правой кнопкой мыши и последовательно выберите пункты Добавить > Новый проект.

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

Этот учебник по началу работы использует Live Unit Testing с платформой тестирования MSTest. Вы также можете использовать платформы тестирования xUnit и NUnit.

Назовите проект StringLibraryTests и щелкните Далее.

Проект модульного теста не может автоматически получить доступ к тестируемой библиотеке классов. Вы предоставляете доступ к библиотеке тестов, добавив ссылку на проект библиотеки классов. Для этого щелкните проект StringLibraryTests правой кнопкой мыши и выберите Добавить > Ссылка. В диалоговом окне Диспетчер ссылок щелкните вкладку Решение и выберите проект StringLibrary, как показано на следующей иллюстрации.

Замените стандартный код модульного теста, включенный в шаблон, следующим кодом:

Сохраните проект, выбрав значок Сохранить на панели инструментов.

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

В раскрывающемся списке Кодировка диалогового окна Дополнительные параметры сохранения выберите параметр Юникод (UTF-8, без сигнатуры), кодовая страница 65001, как показано на следующей иллюстрации:

Скомпилируйте проект модульного теста, выбрав Сборка > Перестроить решение в меню верхнего уровня Visual Studio.

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

Включение Live Unit Testing

Вы уже написали тесты для библиотеки классов StringLibrary, но еще не запускали их. После включения функция Live Unit Testing выполняет их автоматически. Для этого сделайте следующее:

В меню верхнего уровня Visual Studio выберите Тест > Live Unit Testing > Запустить.

Visual Studio запускает функцию Live Unit Testing, которая автоматически выполняет все тесты.

По окончании выполнения обозреватель тестов отображает как общие результаты, так и результаты отдельных тестов. Кроме того, в окне редактора кода выводится графическое представление для результатов тестов и объема протестированного кода. Как показано на следующей иллюстрации, все три теста прошли успешно. Кроме того, видно, что наши тесты охватили все ветви кода в методе StartsWithUpper и все эти тесты были выполнены успешно (на что указывает зеленая галочка "✓"). Наконец, показано, что ни один из других методов в StringLibrary не имеет объем протестированного кода (на что указывает синяя линия "➖").

. moniker range=">=vs-2019" По окончании выполнения Live Unit Testing отображает как общие результаты, так и результаты отдельных тестов. Кроме того, в окне редактора кода выводится графическое представление для результатов тестов и объема протестированного кода. Как показано на следующей иллюстрации, все три теста прошли успешно. Кроме того, видно, что наши тесты охватили все ветви кода в методе StartsWithUpper и все эти тесты были выполнены успешно (на что указывает зеленая галочка "✓"). Наконец, показано, что ни один из других методов в StringLibrary не имеет объем протестированного кода (на что указывает синяя линия "➖").

. moniker-end

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

Щелкните зеленую галочку в строке, где if (String.IsNullOrWhiteSpace(s)) считывается в методе StartsWithUpper . Как показано на следующей иллюстрации, Live Unit Testing указывает, что эту строку кода охватили три теста и все они были выполнены успешно.

Щелкните зеленую галочку в строке, где return Char.IsUpper(s[0]) считывается в методе StartsWithUpper . Как показано на следующей иллюстрации, Live Unit Testing указывает, что эту строку кода охватили только два теста и все они были выполнены успешно.

Основной поднятый Live Unit Testing вопрос — это неполный объем протестированного кода. Ему и посвящен следующий раздел.

Увеличение объема протестированного кода

В этом разделе вы расширите область действия модульных тестов, чтобы они захватывали метод StartsWithLower . При этом Live Unit Testing продолжит динамически тестировать ваш код.

Чтобы увеличить объем протестированного кода, захватив метод StartsWithLower , сделайте следующее:

Добавьте следующие методы TestStartsWithLower и TestDoesNotStartWithLower в файл исходного кода теста проекта:

Измените метод DirectCallWithNullOrEmpty , добавив следующий код сразу после вызова метода Microsoft.VisualStudio.TestTools.UnitTesting.Assert.IsFalse .

Live Unit Testing автоматически выполняет новые и измененные тесты, когда вы изменяете исходный код. Как показано на следующей иллюстрации, все тесты, включая два добавленных и один измененный, были выполнены успешно.

Перейдите в окно, содержащее исходный код для класса StringLibrary. Live Unit Testing показывает, что объем протестированного кода расширен и распространяется на метод StartsWithLower .

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

Пока что все наши тесты прошли успешно. В следующем разделе мы рассмотрим, что делать в случае сбоя теста.

Обработка сбоя при тесте

В этом разделе вы узнаете, как использовать Live Unit Testing для идентификации, диагностики и устранения сбоев тестов. Для этого вы расширите объем протестированного кода, захватив метод HasEmbeddedSpaces .

Добавьте следующий метод в файл теста:

При выполнении теста Live Unit Testing указывает, что произошел сбой метода TestHasEmbeddedSpaces , как показано на следующей иллюстрации:

Выберите окно, где отображается код библиотеки. Для Live Unit Testing был расширен объем протестированного кода с захватом метода HasEmbeddedSpaces . Эта функция также сообщает о сбое теста, добавляя красные значки "🞩" для строк, охваченных непройденными тестами.

Наведите указатель мыши на строку с сигнатурой метода HasEmbeddedSpaces . Live Unit Testing отображает подсказку, сообщающую, что метод охвачен одним тестом, как показано на следующей иллюстрации:

Выберите непройденный тест TestHasEmbeddedSpaces. Live Unit Testing предлагает вам ряд возможностей, в том числе выполнение всех тестов и отладку всех тестов, как показано на этой иллюстрации:

Выберите Отладить все, чтобы отладить непройденный тест.

Visual Studio выполняет тест в режиме отладки.

В тесте каждая строка массива назначается переменной с именем phrase , которая передается в метод HasEmbeddedSpaces . Когда выражение утверждения в первый раз принимает значение false , выполнение программы приостанавливается и вызывается отладчик. Диалоговое окно исключения, полученное в результате непредвиденного значения в вызове метода Microsoft.VisualStudio.TestTools.UnitTesting.Assert.IsTrue , показано на следующей иллюстрации.

Кроме того, для диагностики непройденного теста мы можем использовать все предоставляемые Visual Studio средства отладки, как показано на следующей иллюстрации:

Обратите внимание, что в окне Видимые переменная phrase имеет значение "Name\tDescription", что соответствует второму элементу массива. Метод теста ожидает, что HasEmbeddedSpaces возвращает true при передаче данной строки; вместо этого он возвращает false . Очевидно, он не распознает символ табуляции "\t" как внедренный пробел.

Выберите Отладка > Продолжить нажмите клавишу F5 или кнопку Продолжить на панели инструментов, чтобы продолжить выполнение программы тестирования. Так как возникло необработанное исключение, тест был завершен. Это дает достаточно сведений для предварительного исследования ошибки. Либо подпрограмма тестирования TestHasEmbeddedSpaces сделала неверное допущение, либо HasEmbeddedSpaces неправильно распознает все внедренные пробелы.

Чтобы выявить и устранить проблему, начните с метода StringLibrary.HasEmbeddedSpaces . Посмотрите на сравнение в методе HasEmbeddedSpaces . В нем внедренный пробел считается равным U+0020. Однако в стандарте Юникод есть ряд других пробелов. Это дает основания полагать, что код библиотеки был неправильно протестирован на пробелы.

Live Unit Testing автоматически перезапускает метод непройденного теста.

Live Unit Testing отображает обновленные результаты, в том числе в окне редактора кода.

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

Отладка кода — это один из самых важных процессов. Без отладки в свет не выходит ни одно нормальное приложение. Потому что , независимо от опыта разработчика, код не всегда работает так , как нужно. А иногда и вообще работает совершенно не так. Вот тут как раз и приходит на помощь отладчик, который позволит разобраться , что не так , и найти изъяны. Можно , конечно , много часов провести за самостоятельным выявлением багов, но отладчиком все-таки быстрее и проще.

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

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

Отладка кода в Visual Studio

орфографические ошибки или опечатки,
неправильно подключенные API,
неправильное размещение последних корректировок в код,
и др.

ошибка компиляции;
ошибка преобразования типа;
код не поддерживает синтаксис;
и др .

Как запустить отладчик Visual Studio

Запустить саму программу Visual Studio.
Откр ыть код приложения, который необходимо отладить.
Потом при помощи нажатия клавиши «F5» запустить режим отладки. Также это можно сделать через меню, если нажать «Отладка», а потом «Начать отладку» .

последовательность исполнения кода;
работу памяти;
значение переменных и др.

Какая информация выводится отладчиком Visual Studio

В заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Достаточно часто программистам приходится поддерживать чужой код, очень часто этот код выглядит не самым лучшим образом, и сопровождать его очень сложно. Если это приложение не придется выбросить в скором времени, то естественно его стоит привести в человеческий вид, т.е. отрефакторить. Было бы хорошо иметь какую-нибудь метрику, которая позволила бы оценить качество кода и определить места, которые стоит улучшить. Такая метрика позволила бы оценить, например, то, как программист пишет исходный код или то, насколько качественен код в том приложении, которое Вы собираетесь поддерживать.

Microsoft предоставляет встроенное в Visual Studio средство, которое позволяет оценить код вашего проекта.

Получить оценку вашего кода можно нажав правой кнопкой на проекте и выбрав пункт “Calculate Code Metrics” (Эта функциональность доступна в Visual Studio 2008 Team System и Visual Studio 2010 начиная с Premium версии).

Описание метрик

Результаты содержат 5 метрик для вашего кода.

MI = MAX(0, (171 — 5.2 * ln(HV) — 0.23 * CC — 16.2 * ln(LoC)) * 100 / 171)

HV – Halstead Volume, вычислительная сложность. Чем больше операторов, тем больше значение этой метрики;
CC – Cyclomatic Complexity. Эта метрика описана ниже;
LoC – количество строк кода.

Реальное использование

Когда я первый раз запустил анализ на одном из проектов, все значения Maintainability Index были зеленые. Это казалось несколько странным, т.к. там явно был код, который надо было бы переписать. Значения MI для таких участков кода были около 30-40. Получается, что показатели по умолчанию являются, скорее всего, субъективными, и решение о том, какой код считать некачественным, придется принимать самим программистам.

Для своих проектов я стараюсь для большинства методов поддерживать показатель MI около 70-90. Бывают методы, у которых этот показатель равен 50-60, и их можно переписать, но стоит оценивать затраты и выгоды.

Благодаря этому инструменту можно достаточно легко провести code review большого проекта, найти места, которые необходимо переписать. Также достаточно полезно следить за процессом изменения вышеописанных метрик. Это может показать руководителю об отношении программистов к разработке того или иного проекта, а также динамику изменения качества кода по каждому программисту, что немаловажно в нашей профессии. Другой причиной слежения за метриками, являются, определенные программистами, пороговые значения, при достижении которых, необходимо заняться рефакторингом.

Читайте также: