Из-за природы статической утилиты все тесты обращаются к общему статическому ресурсу, что может иметь отрицательные последствия, как уже наблюдалось.Я предлагаю сделать класс утилит классом экземпляра
public class Utility
{
private Data data;
public Utility(Data data) {
this.data = data;
}
public void Process() {
// Some actions that changes this.data (not reference, just inner Values)
}
}
Какой пример теста будет выглядеть
[Fact]
public void UnitTest1() {
//Arrrange
var data = new Data();
data.Add("val1");
var subject = new Utility(data);
//Act
subject.Process();
//Assert
// check changed data instance
}
Я подозреваю, что проблема initil была XY проблема и что Утилита также используется в качестве статической зависимости в производственном процессе, что является запахом кода.
В этом случае абстрагируйте класс статической утилиты
public interface IUtility {
void Process(Data data);
}
и выполните рефакторинг реализации
public class Utility : IUtility {
public void Process(Data data) {
// Some actions that changes this.data (not reference, just inner Values)
}
}
Что приведет к тому, что тест будет выглядеть как
[Fact]
public void UnitTest1() {
//Arrrange
var data = new Data();
data.Add("val1");
var subject = new Utility();
//Act
subject.Process(data);
//Assert
// check changed data instance
}
[Fact]
public void UnitTest2() {
var data = new Data();
data.Add("another_val1");
data.Add("another_val2");
var subject = new Utility();
//Act
subject.Process(data);
//Assert
// check changed data instance
}
IUtility
будет вставлен в зависимые классы по мере необходимости, что сделает полученный код более SOLID.