Если в прошлый раз речь шла о возможности выполнять заданный код до и после запуска определенных тестов, то в этот раз давайте посмотрим на процесс тестирования в целом. А точнее, разберемся как можно на него повлиять.
[Ещё]
При создании тестов часто возникает необходимость выполнить определенные действия до или после запуска теста или их группы. Например, для подготовки и освобождения ресурсов, создания дополнительных файлов с данными и т. д. MSTest V2 позволяет при помощи атрибутов указать методы, которые будут запущенны в нужные моменты времени.
[Ещё]
Часто одни и те же тесты необходимо выполнить для различного набора данных. Например, проверка валидатора, который гарантирует что длина строки укладывается в заданный интервал. По сути, это не менее четырех тестов, которые отличаются только самой строкой. Конечно, можно просто скопировать тест несколько раз, изменяя строку. Или можно вынести общий код в отдельный метод. Но легче всего воспользоваться возможностями, которые уже есть в MSTest V2.
[Ещё]
При создании тестов с использованием библиотеки MSTest V2 не редко используются только её основные возможности для проверки результата. Это приводит к гораздо большему объему написанного кода и созданию очередных "велосипедов". Посмотрим как можно этого избежать и какая функциональность для проверки результатов тестов есть "из коробки" в данной библиотеке.
[Ещё]
Рассмотрим пример создания NuGet пакета, который может добавлять новые свойства в проект. При помощи данного подхода решим следующую задачу: необходимо поддерживать общий стиль кода в разных проектах, даже если разработка и поддержка осуществляется разными командами.
[Ещё]
Одна из новых возможностей C# 8 – асинхронные потоки. Рассмотрим на примере как её использование может улучшить уже существующий код.
[Ещё]
Иногда возникает ситуация, когда необходимо заново выбросить исключение ex, которое уже было выброшено, перехвачено и записано как внутренне (InnerException) в другом исключении. Проблема заключается в том, что если использовать вызов throw ex, то исходный стек вызова будет заменен на текущий. То есть потеряется важная для отладки информации. Но этого можно избежать.
[Ещё]
Существует три пути использования предварительных версий ASP.NET Core в Azure App Services. Можно установить расширение для App Services. Другим вариантом является развертывание автономного приложения, которое уже содержит нужную версию ASP.NET Core. А в каких-то сценариях удобнее использовать Docker.
[Ещё]
По умолчанию все ответы, созданные с помощью StatusCodeResult и метода контроллера StatusCode(…) возвращают обычный HTTP ответ с кодом статуса. Однако ASP.NET MVC Core позволяет создать контроллер, который для HTTP кодов ошибок (от 400 до 599) будет генерировать ответы в формате, необходимом разработчику.Например для того, чтобы все ответы были в одинаковом формате. Посмотрим как это можно сделать.
[Ещё]
Ошибки случаются. Но после того, как исключение было поймано, возникает серьезный вопрос – что потом делать с полученными данными? Каким образом передать их разработчику, где хранить, как просматривать? Для этого можно изобрести свой "велосипед".
А можно сэкономить время и ресурсы воспользовавшись Application Insights. Это облачная служба аналитики входящая в состав Microsoft Azure. Она позволяет легко собирать и анализировать различную отладочную (и не только) информацию о работе приложения. Давайте посмотрим, как при наличии учетной записи в Azure буквально за несколько минут можно добавить в существующее приложение поддержку записи исключений в журнал.
[Ещё]