UnitTesting статические классы

With out knowing the usage of the class commenting on just the usage is of cause a bit tricky but ill give it a go anyways. To me the above sounds like a smell more than a testing problem.

A static class (just as singletons) are basically a collection of global functions/variables which generally is a bad thing in oop. I'd say trying to test the test issue is (eventhough probably the easiest right now) only fixing the symptom but not the problem.

I'd suggest to take a look at the desing a concidere if you really need the static class or if it just seemed like the easiest way to fix a problem at the time

Ну, вы не указали, какой язык вы используете, но если есть способ открыть ваш статический класс из тестового файла, я бы добавил к нему поддельный деструктор , который вы можете вызывать после каждого теста. Таким образом, «деструктор» останется в тестовом классе и вне вашего производственного кода.

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

public static class MyClass
{
   public static MyClass()
   {
      initialize();
   }

   internal static void initialize()
   {
      // Do initialization (and cleanup if necessary)
   }

   public static void Method1() {}
   public static void Method2() {}
}

Для вызова внутренних методов вам необходимо использовать атрибут InternalsVisibleTo , как описано в этом блоге .

Вы также можете сделать его закрытым, но тогда вам потребуется использовать отражение, чтобы вызвать это.

Но, как сказал Эндрю Шеперд, вам также следует проверить, является ли статический класс лучшим дизайном этого класса.

Вы можете использовать Isolator Typemock , который может имитировать статические классы, поэтому в каждом тесте вы можете «определить», как статика будет работать.

Это не так. хотя и бесплатный продукт.

Похоже, вы пытаетесь протестировать статический конструктор. Это кажется плохой идеей.

Вместо этого рассмотрите возможность выделения логики инициализации в отдельный (нестатический) класс.

Ради обсуждения, допустим, ваш статический класс называется MySingleton, и допустим, вы создаете новый класс MyInitializer с методом Execute. Статический конструктор MySingleton может создать экземпляр MyInitializer и вызвать Execute, который выполняет всю инициализацию.

Тогда ваш производственный код может использовать MySingleton и игнорировать MyInitializer. С другой стороны, ваши тесты могут игнорировать MySingleton и весело создавать новый экземпляр MyInitializer для каждого теста, получая каждый раз новый старт.