Кешируем отдачу картинок в .NET MVC Core

[skovpen]

Snake Case в тестах прям глаза режет. Это же шарпы https://www.dofactory.com/csharp-coding-standards

[sadomovalex]

я его использую только для наименования тестов. Так из названия тестов хорошо видно, что именно тест тестирует - привык🤷‍♂️

[navferty]

Нижнее подчёркивание действительно принято использовать в именах тестов, но чаще всего им отделяют три компонента названия: объект тестирования (например метод), сценарий и ожидаемое поведение, например:

[Fact]
public void Add_SingleNumber_ReturnsSameNumber()
{
    var stringCalculator = new StringCalculator();

    var actual = stringCalculator.Add("0");

    Assert.Equal(0, actual);
}

Взято отсюда https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices#follow-test-naming-standards

[BurkinAnton]

а не лучше вот так? : settingsProvider.Setup(x => x.Get(It.IsAny<string>())).Returns(0);

[sadomovalex]

да, во втором тесте забыл поправить (в реальном коде метод называется GetValue и кроме ключа, там второй аргумент - дефолтное значение, которое возвращается в случае, если настройки нет). Поправил, спасибо

[BibopAiSlop]

Хорошая статья, но режет глаз наследование ImageCacheMiddlewareForTesting для тестов. ASP.NET Core middleware поддерживает Constructor Injection — можно просто инжектить ISettingsProvider напрямую, без виртуальных методов и наследников. Тогда и тесты станут чище, и продакшен-код не придётся менять ради тестирования. А в остальном — подход через middleware годный, спасибо!

[sadomovalex]

спасибо за совет, попробую. Если правильно помню, что-то не завелось через constructor injection именно в middlewares. Это первое, что я пробую обычно, т.к. самый простой и наиболее логичный путь. Для ViewComponents напр. construction injwction завелся, а для middlewares почему-то нет. Но я пробовал это на более ранних версиях MVC Core - тогда нашел рабочий вариант с HttpContext.RequestServices.GetService<T>() и так его и использую с тех пор. Вообщем посмотрю, спасибо👍

[for7raid]

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

Не совсем понятен этот тезис. У вас контроллер и есть то место, которое целиком и полностью отвечает только за http запросы. То,что делается одним атрибутом (вариант 1) или вариант 2 с возможностью читать срок жизни кэша из настроек, вы размазали в избыточные строки кода. Кроме того, ваш промежуточный слой сейчас кэширует вообще все ответы, а это значит что его нужно доработать, добавив в код if условия и, вероятно, связность с нужным контроллером, чтобы понимать нужно кэшировать или нет.

Upd. Увидел, что эту связность вы запихнули вообще в самое неподходящее место - в use. Код стал плохо поддерживаемый.