Как изменить таймаут для конкретного запроса в
Одной из лучших практик по работе с
Однако, возникают ситуации, когда для разных запросов требуется разное поведение клиента. Например, разные таймауты.
Проблема в том, что
Но я бы не писал этот пост, если бы не существовало решения проблемы. А решение довольно простое:
1️⃣ Пользовательский таймаут меньше того, что установлен в
#полезное #tips
HttpClient?Одной из лучших практик по работе с
HttpClient в C# считается переиспользование одного экземпляра клиента для множества запросов. Как минимум во избежание port exhaustion.Однако, возникают ситуации, когда для разных запросов требуется разное поведение клиента. Например, разные таймауты.
Проблема в том, что
HttpClient.Timeout устанавливается единожды, во время создания клиента. И несмотря на наличие public set'тера, это значение не может быть изменено впоследствии. Любые попытки пресекаются выбрасыванием InvalidOperationException.Но я бы не писал этот пост, если бы не существовало решения проблемы. А решение довольно простое:
TimeSpan timeout = GetMyTimeout();Такое решение можно не только использовать "в лоб", но и обернуть в пайплайн из
using (var tokenSource = new CancellationTokenSource(timeout))
{
var response = await httpClient.GetAsync(uri, tokenSource.Token);
HandleResponse(response);
}
DelegatingHandler'ов. Для того чтобы оно работало, потребуется убедиться в двух вещах:1️⃣ Пользовательский таймаут меньше того, что установлен в
HttpClient.Timeout
2️⃣ Пользовательский таймаут валиден. Проще говоря, время ожидания больше 0 секунд.#полезное #tips
❤9👍4
marker interface
Для чего их вообще используют?
Допустим, в коде используется некий объект, который реализует указанный интерфейс. Тогда, появляется возможность проверить реализуется ли он и скорректировать на основе этого обработку объекта.
Также, маркерный интерфейс может быть необходимым злом при отсутствии поддержки в языке discriminated union types.
К сожалению, в объектно-ориентированных языках вроде C# объявить тип, который будет чем-то конкретным из указанного набора, невозможно.
Поэтому, приходится прибегать к таким уловкам.
Почему маркерных интерфейсов стоит избегать?
Главная проблема такого подхода - нарушение инкапсуляции.
Объект сам по себе теперь обладает неявным контролем над возможностями внешнего использования. Более того, он знает окружение, в котором будет использоваться.
Применение маркерного интерфейса подразумевает, что где-то будет находится проверка на этот маркер. Это противоречит идее инкапсуляции, потому что у объекта появляется знание о реализации той части системы, которая находится совершенно вне зоны его «полномочий».
В общем, обычный интерфейс говорит окружающему миру о том как он может быть использован, пустой, маркерный, о том, как должен быть использован.
#полезное #tips
Для чего их вообще используют?
Допустим, в коде используется некий объект, который реализует указанный интерфейс. Тогда, появляется возможность проверить реализуется ли он и скорректировать на основе этого обработку объекта.
Также, маркерный интерфейс может быть необходимым злом при отсутствии поддержки в языке discriminated union types.
К сожалению, в объектно-ориентированных языках вроде C# объявить тип, который будет чем-то конкретным из указанного набора, невозможно.
Поэтому, приходится прибегать к таким уловкам.
Почему маркерных интерфейсов стоит избегать?
Главная проблема такого подхода - нарушение инкапсуляции.
Объект сам по себе теперь обладает неявным контролем над возможностями внешнего использования. Более того, он знает окружение, в котором будет использоваться.
Применение маркерного интерфейса подразумевает, что где-то будет находится проверка на этот маркер. Это противоречит идее инкапсуляции, потому что у объекта появляется знание о реализации той части системы, которая находится совершенно вне зоны его «полномочий».
В общем, обычный интерфейс говорит окружающему миру о том как он может быть использован, пустой, маркерный, о том, как должен быть использован.
#полезное #tips
👍4
На пальцах про AAA
Как вы могли понять речь пойдёт не о батарейках или играх. Сегодняшний пост про юнит-тестирование.
Согласитесь, в таком сложном мире как программирование сложно ориентироваться, когда всё лежит где попало, не на своих местах.
Гораздо проще, когда всё структурировано, лежит, так сказать, по полочкам.
Однажды, умные разработчики подумали, и поняли, что и тесты можно структурировать и разложить на конкретные и понятные этапы.
Arrange
В этой секции находится код, ответственный за настройку теста. Создание объектов, подготовка данных, настройка моков и так далее.
Act
Затем идёт действие. То есть, непосредственно вызов тестируемого функционала.
Assert
Финальный этап - проверка. Проверяется всё что требуется проверить. Какие получились данные, состояние объектов, вызвалось ли то что нужно, была ли ошибка. В общем, есть где развернуться.
Вот и получается, что паттерн Arrange-Act-Assert за счёт своей простоты и эффективности в отношении организации и написания тестов стал де-факто стандартом индустрии.
#полезное #tips
Как вы могли понять речь пойдёт не о батарейках или играх. Сегодняшний пост про юнит-тестирование.
Согласитесь, в таком сложном мире как программирование сложно ориентироваться, когда всё лежит где попало, не на своих местах.
Гораздо проще, когда всё структурировано, лежит, так сказать, по полочкам.
Однажды, умные разработчики подумали, и поняли, что и тесты можно структурировать и разложить на конкретные и понятные этапы.
Arrange
В этой секции находится код, ответственный за настройку теста. Создание объектов, подготовка данных, настройка моков и так далее.
Act
Затем идёт действие. То есть, непосредственно вызов тестируемого функционала.
Assert
Финальный этап - проверка. Проверяется всё что требуется проверить. Какие получились данные, состояние объектов, вызвалось ли то что нужно, была ли ошибка. В общем, есть где развернуться.
Вот и получается, что паттерн Arrange-Act-Assert за счёт своей простоты и эффективности в отношении организации и написания тестов стал де-факто стандартом индустрии.
#полезное #tips
👍9
Do I need to run tests before
На текущем проекте мы используем Kafka. Так вышло, что я - MacBook enjoyer и пишу код на m1 машине.
Соответственно, интеграционные тесты, задействующие Kafka тупо не запускаются.
И какое-то время назад у меня в голове возник вопрос: «а должно ли это вообще меня волновать?»
Ладно, Kafka. Но в большом коммерческом проекте есть ещё много других вещей, которые нужно было бы поднимать на своей машине, просто чтобы запустить приложение:
▪️Эмулятор внешних систем (mock интеграций);
▪️Базы данных;
▪️Кэш;
▪️Gateway микросервисов;
И многое другое…
Зачем мне засорять компьютер, когда уже есть облако с окружением, где крутятся пайплайны, триггернутые коммитом? CI/CD - это автоматизация всей вот этой рутины. И я воспользуюсь этим технологическим достижением, чтобы упростить себе жизнь.
Смысл прогонять тесты на машине, если репорт будет читаться из пайплайна в гитлабе?
#полезное #tips
push?На текущем проекте мы используем Kafka. Так вышло, что я - MacBook enjoyer и пишу код на m1 машине.
Соответственно, интеграционные тесты, задействующие Kafka тупо не запускаются.
И какое-то время назад у меня в голове возник вопрос: «а должно ли это вообще меня волновать?»
Ладно, Kafka. Но в большом коммерческом проекте есть ещё много других вещей, которые нужно было бы поднимать на своей машине, просто чтобы запустить приложение:
▪️Эмулятор внешних систем (mock интеграций);
▪️Базы данных;
▪️Кэш;
▪️Gateway микросервисов;
И многое другое…
Зачем мне засорять компьютер, когда уже есть облако с окружением, где крутятся пайплайны, триггернутые коммитом? CI/CD - это автоматизация всей вот этой рутины. И я воспользуюсь этим технологическим достижением, чтобы упростить себе жизнь.
Смысл прогонять тесты на машине, если репорт будет читаться из пайплайна в гитлабе?
#полезное #tips
👍4❤1🤣1