Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:

S>>Вот я Logger.LogInformation("thing is {thing}", thing); я и замокаю.
·>В смысле будешь выпиливать все логгинг стейтменты при прогоне тестов? Для упавшего теста ты просто не сможешь разобраться почему он упал, если это произошло на билд-сервере вчера ночью. Особенно актуально для какого-нибудь хитрого многопоточного кода.

S>>Суть моков проверить свой код, а не сторонних библиотек. То есть я должен подсунуть свой ответ и проверить различные вариации для проверки своего кода.
·>Но если ты в своём коде используешь хоть какой-нибудь библиотечный код, то всё.

S>>Ты разве моками не занимался?
·>Занимался конечно. Надо создавать моковый инстанс thing, и тогда он может гулять по всему коду где угодно. А мокать call-sites — бесполезно, работает только на игрушечных примерах.
·>В java такой проблемы с моками никогда не было. Стандартно там можно создавать моки для любого класса, который не final (или sealed в терминологии c#). Впрочем, есть ещё PowerMock — она манипуляцией байткода позволяет мокать вообще всё, но это считается bad practice.


Во во создавать кучу интерфейсов и их реализацию. Про это и речь
Еще раз меня не интересуют сторонний код. Меня интересует только свой.
У меня может не быть возможности использовать сторонний код либо по времени исполнения, либо конкретно нельзя подключиться, либо долгая инициализация, а мне надо проверить только конкретный кусок кода итд.
Вот InterceptsLocation как раз для этого прекрасно подходят!

В статье же прямо написано

Хоть польза для AOT здесь также имеется, фокус приходится на кодогенерацию. Например, можно было бы помечтать о библиотеках, упрощающих работу с аспектно-ориентированным программированием. Однако ещё более заманчиво звучат фреймворки для юнит-тестов – наконец-то можно будет перестать делать по интерфейсу на каждый класс, просто чтобы замокать его в тестах. По крайней мере, это активно дискутируется в сообществе, что приятно.