День 1190. #Testing
Тестировать Сначала или Потом
Когда писать тесты: до написания кода или после.

Сначала код
Это обычный подход, а также самый интуитивно понятный способ написания тестов. Сначала пишете код, а затем покрываете его тестами. Ничего сложного: это «нормальный» способ разработки ПО.

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

Процесс TDD
1. Напишите тест
Так вы описываете требования к функциональности, которую скоро разработаете, и формулируете их в виде утверждений в тесте.

2. Убедитесь, что тест завершается неудачей по уважительной причине 
Тест должен завершиться неудачей из-за проблем с тестируемой функциональностью, а не из-за какой-то несвязанной проблемы, типа исключения уровня приложения.

3. Сделайте так, чтобы тест прошёл
Реализуйте реальную функциональность, покрываемую тестом. Здесь качество кода не важно; цель в том, чтобы тест стал зеленым.

4. Рефакторинг
Если нужно, почистите код. Причина отделения этого шага в том, что легче рефакторить существующий беспорядочный код, чем писать чистый код с самого начала.

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

При подходе «сначала код» эту проверку необходимо выполнять вручную: изменить код, чтобы сымитировать ошибку, убедиться, что тест падает, и изменить код обратно. Это утомительно, и многие пропускают этот шаг, что может привести к некорректным тестам. В TDD этот шаг встроен в сам процесс написания кода, т.е. не нужно выполнять какую-либо дополнительную работу.

Преимущества «тестов после»
Гибкость. Т.к. вам не нужно беспокоиться о тестах, вы можете легко менять код приложения: провести рефакторинг или даже полностью перепроектировать его. С тестами сделать это сложнее, потому что придётся исправлять тесты после каждого редизайна.

Когда использовать
Оба подхода нужно применять на нужном этапе вашего проекта. Можно выделить 2 этапа:
1. Делаем что надо
2. Делаем как надо

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

Как только вы уверены, что делаете что надо, можно перейти к этапу 2. Здесь вы можете следовать TDD и получать все долгосрочные преимущества, такие как хорошее тестовое покрытие и качественные тесты.

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

Еще одна область, где TDD полезен — исправление ошибок. Если вы нашли ошибку, не исправляйте ее сразу. Сначала напишите тест для воспроизведения этой ошибки, убедитесь, что он падает, а затем исправьте код. Таким образом, вам больше никогда не придется беспокоиться об этой ошибке.

Источник: https://khorikov.org/posts/2022-01-24-test-first-vs-test-last-approaches/

День 1191.
Подборка тегов, используемых в постах на канале, чтобы облегчить поиск. Не могу гарантировать, что все 1190 постов идеально и корректно помечены тегами, но всё-таки, эта подборка должна помочь.

Общие
Эти посты на совершенно разные темы, помечены этими тегами только с целью различать общую направленность поста.

#ЗаметкиНаПолях – технические посты. Краткие описания теории, особенности языка C# и платформы .NET, примеры кода, и т.п.

#Шпаргалка - примеры кода, команды для утилит и т.п.

#Юмор – шутки, комиксы и просто весёлые тексты или ссылки на видео.

#Оффтоп – всё прочее.


Специализированные
Эти теги более тематические, выделяют основную тему поста.

#Карьера – советы по повышению продуктивности, карьерному росту, прохождению собеседований и т.п.

#Книги – обзоры книг, которые (чаще всего) я лично прочитал, либо ещё нет, но советую прочитать.

#Курсы – обзоры и ссылки на онлайн курсы.

#МоиИнструменты – различные программы, утилиты и расширения IDE, которые я использую в работе.

#ЧтоНовенького – новости из мира .NET.


Узкоспециализированные
Эти теги относятся к определённой узкой теме.

#AsyncTips – серия постов из книги Стивена Клири “Конкурентность в C#”
#AsyncAwaitFAQ – серия постов “Самые Частые Ошибки при Работе с async/await.”

#BestPractices – советы по лучшим практикам, паттернам разработки.

#DesignPatterns – всё о паттернах проектирования, SOLID, IDEALS и т.п.

#DotNetAZ – серия постов с описанием терминов из мира .NET.

#GC – серия постов “Топ Вопросов о Памяти в .NET.” от Конрада Кокосы.

#MoreEffectiveCSharp – серия постов из книги Билла Вагнера “More Effective C#”.

#Testing – всё о тестировании кода.

#TipsAndTricks – советы и трюки, в основном по функционалу Visual Studio.

#Quiz - опросы в виде викторины.

#97Вещей – серия постов из книги “97 Вещей, Которые Должен Знать Каждый Программист”.

#ВопросыНаСобеседовании – тег говорит сам за себя, самые часто задаваемые вопросы на собеседовании по C#, ASP.NET и .NET.
#ЗадачиНаСобеседовании – похоже на вопросы, но здесь больше приводятся практические задачи. Чаще всего это 2 поста: собственно задача и ответ с разбором.

#КакСтатьСеньором – серия постов «Как Стать Сеньором» с советами о продвижении по карьерной лестнице.

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

День 1192. #Оффтоп
Сегодня порекомендую ещё одно очень крутое и познавательное выступление с NDC Conference Oslo, которая проходила в конце 2021 года. Доклад Дилана Бити называется «Plain Text».

Программное обеспечение – это сложно. Машинное обучение, архитектуры микросервисов, очереди сообщений... Каждые несколько месяцев появляется ещё одна революционная идея, которую нужно изучать, ещё одна инфраструктура. И в основе всех этих удивительных идей и абстракций лежит текст. Когда вы работаете с программным обеспечением, вы постоянно работаете с текстом. Некоторые из этих текстовых файлов являются исходным кодом, некоторые — конфигурационными файлами, некоторые — документацией. Редакторы, системы контроля версий, языки программирования — всё, от C# и HTML до Git и VS Code, основано на идее «простых текстовых файлов». Но не всё так просто.

Когда мы говорим, что что-то является «простым текстовым файлом», мы полагаемся на огромное количество предположений: об операционных системах, редакторах, форматах файлов, языке, культуре, истории… и в большинстве случаев это нормально. Но когда что-то идёт не так, «обычный текст» может привести к самым странным ошибкам, которые вы когда-либо видели. Почему в журналах событий Windows появляется китайский язык? Почему город Орхус находится не в том месте при упорядочивании по алфавиту? Что такое Kohuept? И почему у Магнуса Мортенссона всегда проблемы с въездом в США? Дилан Битти рассказывает о мире текстовых файлов: от истории механических телетайпов до кодировок, сопоставлений и кодовых страниц. Разбирает памятные баги и золотые правила работы с простым текстом. Кстати, кириллица в докладе разбирается довольно подробно.

День 1193. #ЗаметкиНаПолях #TipsAndTricks
Временно Изменяем CurrentCulture
Иногда для тестирования некоторых функций вам требуется изменить культуру потока, в котором работает приложение. Текущая культура определяется в глобальном свойстве Thread.CurrentThread.CurrentCulture.

Создадим класс, который реализует интерфейс IDisposable, чтобы иметь ограниченный блок кода, в котором будет использоваться новая культура:

public class TempCulture : IDisposable
{
  CultureInfo _old;

  public TempCulture(CultureInfo culture)
  {
    _old = CultureInfo.CurrentCulture;
    Thread.CurrentThread.CurrentCulture = culture;
  }

  public void Dispose()
  {
    Thread.CurrentThread.CurrentCulture = _old;
  }
}

В конструкторе сохраняем текущую культуру в приватном поле. Затем, когда мы вызываем метод Dispose (который неявно вызывается при закрытии блока using), мы используем это значение для восстановления исходной культуры.

Например, проверим символ валюты:

Thread.CurrentThread.CurrentCulture = 
  new CultureInfo("ja-jp");

Console.WriteLine(
  Thread.CurrentThread.CurrentCulture
   .NumberFormat.CurrencySymbol
 );
//￥

using (new TempCulture(new CultureInfo("ru-ru")))
{
  Console.WriteLine(
    Thread.CurrentThread.CurrentCulture
      .NumberFormat.CurrencySymbol
  );
  //₽
}

Console.WriteLine(
  Thread.CurrentThread.CurrentCulture
    .NumberFormat.CurrencySymbol
);
//￥

Сначала мы устанавливаем культуру текущего потока на японскую, и получаем символ валюты – йену ￥. Затем временно переходим на русскую культуру и в консоль выводится рубль ₽. Наконец, когда мы выходим за пределы блока using, мы снова получаем йену.

Итого
Использование класса, реализующего IDisposable, — хороший способ создать временную среду с характеристиками, отличными от характеристик основной среды.

Источник: https://dev.to/bellonedavide/c-tip-how-to-temporarily-change-the-currentculture-2bp7

День 1194. #Testing
Стоимость Кода
Сегодняшний пост посвящён долгосрочным последствиям наших решений в процессе разработки программного обеспечения.

Вопрос
Простые однострочные свойства слишком тривиальны. Стоит ли их тестировать? Ведь в крупных или долгосрочных проектах кто-то может изменить их. Правильно ли предполагать, что их поведение никогда не изменится? Написать тест для них просто и займёт всего минуту.
Разве уверенность в том, что никто случайно не сломает ваш код, подправив сеттеры и геттеры, не оправдывает написание чрезвычайно простых модульных тестов?

Этот вопрос стоит разделить его на две части.

1. Правильно ли предположить, что поведение «однострочников» никогда не изменится?
Нет необходимости это предполагать. Вы можете протестировать этот код, как только он станет достаточно сложным. Именно здесь становятся полезными инструменты покрытия кода. Покрытие кода - недостаточный показатель для определения качества ваших тестов. Но эти метрики всё же полезны в некоторых сценариях. Один из них — видеть, какие части вашего кода тестируются, а какие нет.

Инструменты анализа покрытия кода позволяют увидеть добавление сложности (например, ветвления) в эти простые свойства. И вы заметите, что часть этой сложности не проверена.

2. Долгосрочная и краткосрочная стоимость кода
Написание модульных тестов для этих однострочников тривиально и занимает всего минуту для каждого.
Написать такие тесты действительно легко. Но это не главная проблема. Стоимость здесь состоит из двух частей:
- Написание такого теста
- Поддержание его на протяжении всего жизненного цикла проекта
И вторая часть гораздо важнее первой.

Написание кода — это одноразовое действие, вам нужно сделать это только один раз. С другой стороны, чтение и сопровождение кода — непрерывный процесс. Затраты на этот процесс со временем увеличиваются. Рассмотрим все действия, которые становятся более затратными по мере добавления новых тестов:
- Рефакторинг тестов при рефакторинге тестируемого кода
- Запуск дополнительных тестов при каждом изменении кода
- Обработка ложных срабатываний
- Затраты времени на чтение тестов, когда вы пытаетесь понять, как ведет себя тестируемый код

Если это кажется слишком трудоёмким – это потому, что так оно и есть. Следовательно, вы должны уделять очень пристальное внимание тому, какие тесты вы добавляете в свой набор тестов. Лучше вообще не писать тест, чем писать малоценный тест, даже если сам этот тест простой.

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

Источник: https://khorikov.org/posts/2021-09-27-cost-of-code/

День 1195. #Карьера
6 Вещей, Которым я Научилась за Полгода Работы Тимлидом
"Не прошло и полугода, как я заняла должность руководителя группы. Я пришла из небольшой компании, где неофициально руководила проектом. Вот 6 главных вещей, которые я лично усвоила, став тимлидом на крупном проекте."

1. Больше встреч, меньше времени на разработку - это неизбежно
Несмотря на то, что меня заверили, что я по-прежнему буду выполнять большую часть работы по разработке, это вскоре прекратилось, поскольку увеличились затраты времени на другие обязанности. Особенно в периоды, когда мы нанимали сотрудников, и мне приходилось часами просматривать резюме и сидеть на собеседованиях. В среднем я бы сказала, что практическое время на разработку сократилось до 50% или даже меньше.

2. Повседневный менеджмент требует много времени и усилий
Повседневное управление — это не только приём заявок на отпуск или ответы на странные вопросы — обычно это гораздо больше. В моей компании мы проводим встречи один на один раз в две недели. С командой из 5 человек это оказалось неожиданно много! И в них мне приходилось помогать с постановкой целей и следить за тем, чтобы все были довольны, не упуская из виду рабочую нагрузку коллег и их цели.
Кроме того, адаптация новичков тоже занимает много времени — я не тот человек, который хочет бросать людей в пекло без поддержки, поэтому я не тороплюсь, помогаю им, чтобы убедиться, что у всех всё в порядке.

3. Не все сразу признают ваше лидерство
В самом деле, кажется, некоторые до сих пор не признают меня как начальника! Одно дело получить повышение, а другое — заслужить уважение окружающих. Особенно, когда вы относительно новичок в компании, а коллеги могут работать там уже некоторое время, поэтому вы, вероятно, не так хорошо знаете процессы и продукт.
Добавьте к этому тот факт, что я довольно молода для этой должности, плюс женщина. Так что мне пришлось много работать, чтобы доказать, что я достойна и способна руководить командой.

4. Твоя задача не в том, чтобы быть лучшим в команде
Это важно, но это не то же самое, что быть сеньором. Раньше меня считали техническим экспертом, и я давала советы по дизайну и реализации. Мне нравился процесс обсуждения решений с другими разработчиками. Однако теперь, когда я занимаю руководящую роль, я вместо этого должна признавать сильные стороны членов моей команды и создавать среду, которая поощряет членов команды вносить свой вклад. В противном случае вы столкнётесь с неприятным ярлыком «микроменеджера» или «диктатора»!
Это не значит, что вы не можете иметь своё мнение или быть экспертом, но вы не должны заставлять всех делать что-то по-вашему только потому, что вы главный.

5. Не все хотят, чтобы ими «управляли»
Некоторым людям не нужен менеджер, некоторые не хотят, чтобы их тренировали или наставляли. Вы просто не можете заставить их участвовать в процессе. И это нормально. Однако, если они активно сопротивляются вам или проявляют неуважение, это не нормально. Должно присутствовать взаимное уважение.

6. Я реально ненавижу конфронтацию
В трудные времена мне приходилось набираться смелости, чтобы противостоять людям и брать ответственность на себя. Это то, над чем мне придётся продолжать работать, потому что это не было естественно для меня!
Конфронтация не означает проявления агрессии или жарких споров, но если вы менеджер, вы не можете избежать её, если кто-то не справляется, ведёт себя грубо или ещё каким-то образом создаёт проблему. Вы, как руководитель группы, несёте ответственность за разрешение конфликтов.
Однако иногда это действительно отстой! Я хочу хороших рабочих отношений с людьми, с которыми я работаю, и чтобы окружающая среда была дружелюбной и веселой. Однако, как менеджер, я просто не могу всегда всем нравиться.

Источник: https://katycodesstuff.hashnode.dev/the-top-6-things-ive-learnt-after-6-months-as-a-team-lead
Автор оригинала: Katy A

День 1196. #ЗаметкиНаПолях
Правила Кода
Roslyn имеет очень большой набор анализаторов для проверки качества вашего кода, но вы должны включить эти анализаторы, прежде чем они начнут что-то делать. Сегодня рассмотрим краткую информацию о том, почему важно включать эти анализаторы в ваши проекты C#, как это сделать и как их настроить.

Правила кода — это правила, которые компилятор или инструмент анализа кода применяет на уровне сборки. Они обеспечивают соблюдение соглашений о кодировании, выявляют ошибки и предоставляют инструменты для исправлений. Roslyn и другие инструменты .NET/C# используют статический анализ кода, чтобы проверить, где в вашем коде есть нарушения. Rider и Resharper предоставляют инструменты статического анализа кода поверх существующего анализа кода от Roslyn.

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

Без правил кода этот код компилируется нормально:

public static class Program
{
  public static void Main() => 
    Console.WriteLine(
      string.Format(new CultureInfo("en-US"), 
      "Hello {0}{1}!", "World")
    );
}

Однако, когда мы включаем правила кода, анализатор сообщит нам, что есть ошибка. Если мы правильно настроим правила кода, мы не сможем собрать приложение. Эту ошибку удастся предотвратить ещё до того, как мы запустим тесты. Бесчисленные правила могут помочь вам улучшить качество кода, производительность, удобочитаемость и найти более простые способы написания кода.

Правила кода включаются на уровне csproj, а затем можно изменить файл editorconfig для отдельных правил. Нужно добавить Nuget пакет Microsoft.CodeAnalysis.NetAnalyzers (Roslyn Analysers). Это самый распространённый набор анализаторов. Они работают на всех IDE и платформах и внутри конвейеров CI/CD. Вы также можете добавить другие пакеты Nuget для дополнительных анализаторов.

Если в вашем решении несколько проектов, нужно переместить конфигурацию в файл Directory.Build.props. Это позволит совместно использовать параметры проекта для нескольких проектов в вашем решении.

Гораздо проще начать со всеми включенными правилами и собрать решение с полным анализом кода. Однако вы можете настроить каждое правило отдельно. Добавьте файл editorconfig в своё решение. Можно настраивать правила как в визуальном редакторе, так и отредактировать файл напрямую как текст. Справочник по конфигурации можно найти здесь.

Рекомендуется включить все правила кода и постепенно исправлять ошибки, с которыми вы сталкиваетесь в своём решении. Существуют инструменты массового исправления, которые помогут вам решить многие проблемы. Команда CLI dotnet format применит множество исправлений, но чаще бывает безопаснее применять исправления для правил по одному вручную. Устранение всех проблем может занять некоторое время. Однако не нужно исправлять все нарушения правил кода за один раз.

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

Источник: https://christianfindlay.com/2022/04/24/code-rules/

День 1197. #юмор
Шпаргалка по кодам ответов HTTP.

День 1198. #ЧтоНовенького
Обновления ASP.NET Core в .NET 7 Превью 4. Начало
Недавно вышедший превью 4 .NET 7 включает много отличных обновлений в ASP.NET Core.

1. Улучшения производительности HTTP/2
Значительно переработана обработка сервером Kestrel запросов HTTP/2. HTTP/2 позволяет параллельно выполнять до 100 запросов по TCP-соединению. Это называется мультиплексированием. До превью 4 мультиплексирование HTTP/2 в Kestrel основывалось на блокировке через ключевое слово lock для управления тем, какой запрос может записывать в TCP-соединение. Хотя блокировка — это простое решение для написания безопасного многопоточного кода, она неэффективна при высокой конкуренции потоков.

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

Решение состоит в том, чтобы переписать, как запросы HTTP/2 в Kestrel получают доступ к TCP-соединению. Потокобезопасная очередь заменяет блокировку записи. Вместо того, чтобы бороться за то, кто может использовать блокировку записи, теперь запросы выстраиваются в очередь, и их обрабатывает выделенный потребитель. Ресурсы ЦП, которые ранее тратились впустую, теперь доступны остальной части приложения.

Эти улучшения видны в gRPC, популярной среде RPC, использующей HTTP/2.

2. Типизированные результаты для минимальных API
В .NET 6 представили интерфейс IResult для предоставления значений, возвращаемых из минимальных API, которые не используют неявную поддержку сериализации JSON возвращённого объекта в ответ HTTP. Статический класс Results используется для создания различных объектов IResult, представляющих различные типы ответов, от простой установки кода ответа до перенаправления на другой URL-адрес. Однако типы инфраструктуры, реализующие IResult, возвращаемые этими методами, были внутренними, что затрудняло проверку конкретного типа IResult, возвращаемого методами API, в модульных тестах.

В .NET 7 типы, реализующие IResult в ASP.NET Core, стали общедоступными, что позволяет использовать простые утверждения при тестировании. Пусть у нас есть следующий метод API:

public async Task<IResult> GetTodos(TodoDb db)
{
  return Results.Ok(
    await db.Todos.ToArrayAsync()
   );
}

Тогда проверить результат метода можно следующим образом:

var db = CreateDbContext();
var result = await api.GetTodos(db);
Assert.IsType<Ok<object>>(result);

Обратите внимание, что тип результата — Ok<object>, поскольку метод Results.Ok(object? value = null) принимает значение как объект, а не как исходный тип. Чтобы решить эту проблему, введён новый фабричный класс для создания «типизированных» результатов.

Новый статический класс Microsoft.AspNetCore.Http.TypedResults является «типизированным» эквивалентом существующего класса Microsoft.AspNetCore.Http.Results. Вы можете использовать TypedResults в минимальных API для создания экземпляров типов, реализующих IResult, c сохранением информации о конкретном типе.

Тогда пример выше можно переписать с использованием TypedResults:

public async Task<IResult> GetTodos(TodoDb db)
{
  return TypedResults.Ok(
    await db.Todos.ToArrayAsync()
   );
}

И протестировать уже типизированный результат:

var db = CreateDbContext();
var result = await todosApi.GetTodos(db);
Assert.IsType<Ok<Todo[]>>(result);

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

Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-4/

День 1199. #Testing
Тестирование в Реальной Жизни. Начало
Коротко о различных нестандартных типах тестов и о том, что нужно иметь в виду при их использовании.

1. Тесты бизнес-логики
Эти тесты включают в себя всё, что подтверждает, что ваша бизнес-логика работает: модульные тесты, интеграционные тесты, сквозные тесты и т. д. Конкретная их реализация может варьироваться, но суть в том, что они должны проверять бизнес-цели кода, а не его техническую структуру. Здесь нас не заботят приватные методы, вызываются ли методы в правильном порядке, правильность параметров или что-либо ещё техническое. Просто нужно убедиться, что вывод соответствует вашим ожиданиям.

Избегайте любых непроизводственных компонентов (имитаций). Используйте реальные базы данных, реальные конечные точки и т. д. Имитируйте их, только если вам нужно сделать тесты более надёжными или быстрыми. Не имеет значения, что тесты проходят, если приложение не работает. Убедитесь, что вы проверяете все уровни вашего ПО, включая сетевые рукопожатия, авторизацию/аутентификацию, разрешения и т. д. В идеале используйте инфраструктуру как код для создания новой среды тестирования каждый раз.

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

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

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

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

Когда у вас есть логи для сравнительных тестов, вы достигаете ещё двух вещей: корректности кэша и базы данных в тестовой среде. После исполнения сравнительных тестов ваш тестовый кэш готов обслуживать трафик на полной скорости. Это очень важно, поскольку кэш должен быть масштабирован, чтобы поддерживать стабильное соотношение попаданий, чего может быть трудно достичь с поддельными запросами. Кроме того, теперь тестовая база данных заполнена достаточным количеством данных и, что более важно, реальными записями из реальной жизни.

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

Окончание следует…

Источник: https://blog.adamfurmanek.pl/2022/02/19/types-and-programming-languages-part-9/

День 1200. #Testing
Тестирование в Реальной Жизни. Окончание
Коротко о различных нестандартных типах тестов и о том, что нужно иметь в виду при их использовании.

Начало

3. Выпуск в производство
На тестовой лаборатории всё не заканчивается. При развёртывании в рабочей среде нужно следовать некоторому регламенту. Обычно есть три подхода.

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

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

Третий подход заключается в использовании A/B-тестов или любых переключателей. Вы просто реализуете условие if в своем коде, которым вы можете управлять с помощью некоторого переключателя после развертывания. Таким образом, сначала парк работает только с кодом A. Затем развёртывается приложение с кодом A и B и запускается только код A, потому что переключатель выключен. После развёртывания можно выборочно включить код B на нескольких хостах. Это хорошо, потому что можно контролировать, сколько клиентов получат новое поведение, и легко откатить его. Однако, помимо недостатков предыдущего решения, это также создаёт риск возникновения ошибки в условии if. Не говоря уже о том, что, если у вас несколько переключателей, может быть сложно отследить, что происходит.

4. Повторяющиеся тесты
Имейте в виду, что после развёртывания в рабочей среде всё равно следует повторить тесты бизнес-логики. Недостаточно предположить, что если что-то работало правильно в пре-продакшне, то и в продакшене всё будет хорошо. В рабочей среде используется другая сетевая инфраструктура, другие хосты, другие базы данных, поэтому нужно повторить тесты, чтобы быть уверенным, что всё работает правильно или же откатить изменения.

5. Тесты на проникновение
Аналогичный принцип применим и к тестам на проникновение. Их нужно запускать во всех средах. Производственная среда должна быть физически отделена от среды тестирования, поэтому необходимо убедиться, что конфигурация рабочей среды безопасна и надёжна.

Источник: https://blog.adamfurmanek.pl/2022/02/19/types-and-programming-languages-part-9/

День 1201. #Курсы
Челлендж Microsoft Build Cloud Skills
Выполните задание и получите бесплатный пропуск на сертификационный экзамен Microsoft.

На выбор доступно 8 испытаний, выберите то, что подходит именно вам. После того, как вы выполните задание, вы получите бесплатный пропуск на сертификационный экзамен Microsoft, который может быть применён для любого из следующих экзаменов:
- AI-102: Designing and Implementing a Microsoft Azure AI Solution
- AZ-204: Developing Solutions for Microsoft Azure
- AZ-220: Microsoft Azure IoT Developer
- AZ-400: Designing and Implementing Microsoft DevOps Solutions
- DP-420: Designing and Implementing Cloud - Native Applications Using Microsoft Azure Cosmos DB
- MS-600: Building Applications and Solutions
- PL-100: Microsoft Power Platform App Maker
- PL-200: Microsoft Power Platform Functional Consultant
- PL-300: Microsoft Power of BI Data Analyst
- SC-200: Microsoft Security Operations Analyst
- SC-300: Microsoft Identity and Access Administrator

Челлендж начинается 24 мая 2022 г. в 16:00 UTC и заканчивается 21 июня 2022 г. в 16:00 UTC. Убедитесь, что все модули вашего задания завершены, прежде чем истечёт время.

Если вы выполните задание до истечения срока, в вашем профиле Microsoft Learn 30 июня 2022 г появится пропуск на один сертификационный экзамен Microsoft.

Правила
- Вы можете претендовать только на один пропуск на человека, независимо от количества выполненных испытаний.
- Пропуск может быть использован для сдачи одного сертификационного экзамена Microsoft, который проводится в авторизованном центре тестирования Pearson Vue или на сайте Pearson Vue до 31 декабря 2022 г.

Подпишитесь на рассылку, чтобы получить уведомление, когда начнётся челлендж: https://www.microsoft.com/en-us/cloudskillschallenge/build/registration/2022

День 1202. #ЗаметкиНаПолях
Список Всех Маршрутов в ASP.NET Core
Когда ваше приложение ASP.NET Core станет достаточно большим, вам может понадобиться полное представление обо всех маршрутах. Существует несколько способов объявления маршрутов. Вы можете использовать минимальные API, контроллеры, Razor Pages, gRPC, HealthCheck и т. д. Но все они используют одну и ту же систему маршрутизации под капотом.

Коллекция маршрутов может быть указана путем извлечения коллекции EndpointDataSource из DI.

Пример для минимальных API:

if (app.Environment.IsDevelopment())
{
  app.MapGet("/debug/routes", 
   (IEnumerable<EndpointDataSource> sources) =>
    string.Join("\n", sources.SelectMany(s => s.Endpoints)));
}

Добавление этого блока в пример приложения из документации выведет следующие маршруты:

HTTP: GET /
HTTP: GET /todoitems
HTTP: GET /todoitems/complete
HTTP: GET /todoitems/{id}
HTTP: POST /todoitems
HTTP: PUT /todoitems/{id}
HTTP: DELETE /todoitems/{id}
HTTP: GET /debug/routes

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

public string Get([FromServices] 
 IEnumerable<EndpointDataSource> sources)
{
  var sb = new StringBuilder();
  var endpoints = 
    sources.SelectMany(s => s.Endpoints);
  foreach (var e in endpoints)
  {
    sb.AppendLine(e.DisplayName);
 
    if (e is RouteEndpoint re)
      sb.AppendLine(re.RoutePattern.RawText); 
  }

  return sb.ToString();
}

Источник: https://www.meziantou.net/list-all-routes-in-an-asp-net-core-application.htm

День 1203. #ЧтоНовенького
Превью 4 Обновлений ASP.NET Core в .NET 7. Продолжение
Продолжаем рассматривать обновления ASP.NET Core в превью 4 .NET 7.
Начало

3. Возврат нескольких типов результатов из минимальных API
Новые обобщённые объединяющие типы Results<TResult1, TResult2, TResultN> вместе с классом TypesResults можно использовать для объявления того, что обработчик маршрута возвращает несколько конкретных типов, реализующих IResult. Любые из этих типов, реализующие IEndpointMetadataProvider, добавят метаданные для конечной точки, позволяя платформе автоматически добавлять описания типов HTTP-результатов для API в OpenAPI/Swagger:

app.MapGet("/todos/{id}", 
  async Results<Ok<Todo>, NotFound> (int id, TodoDb db)
{
  return await db.Todos.FindAsync(id) is Todo todo
    ? TypedResults.Ok(todo)
    : TypedResults.NotFound();
});

В этом случае в описании OpenAPI/Swagger этот метод будет иметь 2 типа типов HTTP-результата: HTTP 200 OK и HTTP 404 NotFound.

Объединяющие типы Results<TResult1, TResultN> реализуют операторы неявного приведения, чтобы компилятор мог автоматически преобразовывать типы, указанные в обобщённых аргументах, в экземпляр объединяющего типа. Это даёт дополнительное преимущество. Во время компиляции проверяется, что обработчик маршрута на самом деле возвращает только те результаты, которые он декларирует. Попытка вернуть тип, который не объявлен как один из обобщённых аргументов в Results<>, приведет к ошибке компиляции.

4. Промежуточное ПО для ограничений
Предоставляет удобный способ задания ограничений для входящих HTTP-запросов. Например, ConcurrencyLimiter позволяет ограничить количество одновременных входящих запросов:

app.UseRateLimiter(new RateLimiterOptions
{
  Limiter = PartitionedRateLimiter
   .Create<HttpContext, string>(resource =>
  {
    return RateLimitPartition
     .CreateConcurrencyLimiter("MyLimiter",
       _ => new ConcurrencyLimiterOptions(
        2, QueueProcessingOrder.NewestFirst, 3));
  })
});

Строка, переданная в качестве первого аргумента CreateConcurrencyLimiter, - это ключ, чтобы различать разные ограничители в PartitionedRateLimiter.

В этом примере используется ConcurrencyLimiter с ограничением в 2 одновременных доступа, параметром, указывающим, что запросы должны обрабатываться по очереди по мере поступления и параметром, задающим размер очереди в 3 запроса.

На данный момент RateLimitPartition содержит методы для создания ConcurrencyLimiter, TokenBucketRateLimiter и NoopLimiter, которые используются аналогично примеру выше.

Подробнее про возможности ограничителя рассказывает Ник Чапсас в своём недавнем видео.

Реализация ограничений в превью 4 .NET 7 пока минимальна и не поддерживает раздельные конечные точки. В будущем планируется это реализовать, а также добавить дополнительные параметры конфигурации. Пока можно использовать System.Threading.RateLimiting для создания PartitionedRateLimiter, который может применять различные ограничения к различным конечным точкам.

Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-4/

День 1204.
В очередной раз неведомые алгоритмы ютуба подкинули мне интересное видео.
Sergei Calabonga рассказывает о собственном фреймворке Nimble Framework, предназначенном для быстрого создания микросервисов.

https://youtu.be/xijBGwMEL8E

Фреймворк предоставляет готовые шаблоны проектов для микросервисов с авторизацией через OpenIddict (бесплатной альтернативой IdentityServer). Кстати, IdentityServer также можно использовать, изменив настройки. Подойдёт тем, кому часто приходится создавать микросервисы с авторизацией и постоянно прописывать одни и те же настройки.

Недавно Сергей выпустил версию 6.1 фреймворка, о которой и рассказывает в этом видео.

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