Насколько наша программа стала быстрее? Производительность зависит от множества факторов, и точных чисел я вам не назову. Условно можно считать, что асинхронный код на том же железе обрабатывает в 3–5 раз больше запросов, чем параллельный.
Так о какой производительности речь? Допустим, у меня производительность ассоциируется со скоростью выполнения запроса. А скорость выполнения запроса в асинхронном коде будет в среднем ниже. А тут будто бы вы говорить про пропускную способность (throughput). Тогда да, за счет утилизации ресурсов асинхронный код будет обладать большей пропускной способностью.
Такие заявления могут ввести в заблуждение и там где надо получить перформанс вдруг начнут делать асинхронность.
Не совсем понятно какую проблему решали и как-то слиплись Unit тесты и интеграционные.
В случае Unit тестов все-таки не так сложно инициализировать SUT (system/service under test) в отдельном методе/конструкторе и тп. Следуя правилу 1 класс и 1 набор тестов, но даже в случае если не так то можно разделить на папки и рядом положить хэлпер с инициализацией.
В случае с интеграционными тестами все-таки есть TestHost из которого можно получать ServiceProvider, но в целом звучит тоже довольно странно, потому что уместнее тут тестировать через endpoint'ы (web api/consumer/cron job и тд), тогда и контейнер брать из хоста не надо.
И в заключении, сейчас кажется нет проблем запускать окружение для полноценных тестов, в том же gitlab делается не так сложно (спасибо контейнерам), почти для всех внешних зависимостей есть легкие контейнеры чисто для тестирования, а для мока внешних вызовов можно использовать mountebank
Так о какой производительности речь?
Допустим, у меня производительность ассоциируется со скоростью выполнения запроса.
А скорость выполнения запроса в асинхронном коде будет в среднем ниже.
А тут будто бы вы говорить про пропускную способность (throughput).
Тогда да, за счет утилизации ресурсов асинхронный код будет обладать большей пропускной способностью.
Такие заявления могут ввести в заблуждение и там где надо получить перформанс вдруг начнут делать асинхронность.
Не совсем понятно какую проблему решали и как-то слиплись Unit тесты и интеграционные.
В случае Unit тестов все-таки не так сложно инициализировать SUT (system/service under test) в отдельном методе/конструкторе и тп. Следуя правилу 1 класс и 1 набор тестов, но даже в случае если не так то можно разделить на папки и рядом положить хэлпер с инициализацией.
В случае с интеграционными тестами все-таки есть TestHost из которого можно получать ServiceProvider, но в целом звучит тоже довольно странно, потому что уместнее тут тестировать через endpoint'ы (web api/consumer/cron job и тд), тогда и контейнер брать из хоста не надо.
И в заключении, сейчас кажется нет проблем запускать окружение для полноценных тестов, в том же gitlab делается не так сложно (спасибо контейнерам), почти для всех внешних зависимостей есть легкие контейнеры чисто для тестирования, а для мока внешних вызовов можно использовать mountebank
выглядит как велосипед, а чем распределенная трассировка плоха ? там можно смотреть граф запросов