Оказывается в спанах в C# нужно еще разбираться и разбираться.
Мне в повседневной работе это вообще не нужно, но интересно как это работает.
Вообще, в оптимизации тестов по скорости выполнения(это одна часть моей работы) самые большие гейны в скорости прогона тестов приходят из параллелизации(тут ясно) и следования тестовой пирамиде.
Если вы оптимизируете тесты по скорости выполнения как-то иначе, то скорее всего это трата времени и смотрите вы не туда. Тут стоить заметить, я говорю о довольно больших фреймворках автоматизации с количеством тестов >100(но это цифра из головы, зависит от типа тестов) и это не о юнит тестах(с ними уже больше смысла биться за скорость выполнения).
А причин почему тестовая пирамида может быть сломана уйма, но вот одна. У вас есть множество автоматизированных тестовых сценариев, которые тестируют функциональность внахлест(происходит тестирование одной функциональности по нескольку раз), это очень частый случай, но предпосылки могут быть разными. Случиться это может, например, из-за непонимания домена или архитектуры приложения. Человек может не понимать, что проверяя функциональность(или часть системы) А он еще проверяет функциональность Б, которая может использоваться неявно или использоваться в каких-то эдж кейсах и тестировать явно ее не нужно, но на нее тоже написаны тесты. Или функциональности А сначала не было, а была только Б и тесты на неё. Или несколько команд использующих один фреймворк автоматизации, но работающих над разными частями системы могут создавать тесты для того, что возможно уже покрыто другой командой, и это уже проблема коммуникации и трейсабилити(блять, смотря какой фабрик, traceability, как это по-русски?), которая решается не оптимизациями в коде и может быть предотвращена сбором и оценкой соответствующих метрик.
Вообще тут очень много оговорок и нужно писать статью.
А про спаны интересно, да, я просто видео хотел запостить.