Как установить ErrorCode для ManagementException?

Наименьшее усилие для преодоления этого препятствия было бы статическим вспомогательным / служебным методом, который использует отражение для взлома слота в требуемом коде ошибки. Используя самый лучший Reflector, я вижу, что есть частное поле «errorCode», которое устанавливается только через внутренние ctors, определенные в ManagementException. Так :)

public static class EncapsulationBreaker
   {
      public static ManagementException GetManagementExceptionWithSpecificErrorCode(ManagementStatus statusToBeStuffed)
      {
         var exception = new ManagementException();
         var fieldInfo = exception.GetType().GetField("errorCode", 
            BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField | BindingFlags.DeclaredOnly);
         fieldInfo.SetValue(exception, statusToBeStuffed);
         return exception;
      }
   }

Проверено, что это работает

[Test]
      public void TestGetExceptionWithSpecifiedErrorCode()
      {
         var e = EncapsulationBreaker.GetManagementExceptionWithSpecificErrorCode(ManagementStatus.BufferTooSmall);
         Assert.AreEqual(ManagementStatus.BufferTooSmall, e.ErrorCode);
      }

Хотя обычно я не одобряю размышления в тестах, это один из редких случаев, когда это необходимо/полезно.
HTH

Получите класс от ManagementException и скройте реализацию кода ошибки своей собственной. Пусть ваш макет вернет этот класс.

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

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

Я бы подклассировал ManagementException и в подклассе переопределил геттер ErrorCode (если обычные уровни защиты мешают вам сделать это, возможно, самоанализ может приблизить вас). Любой код, который обрабатывает ManagementException, но никогда не слышал о вашем конкретном подклассе, должен обрабатывать ваш подкласс "как если бы" это был ManagementException, который вы пытаетесь смоделировать для целей тестирования, в конце концов.

Изменить: вполне возможно, что ErrorCode просто нельзя переопределить (я ненавижу языки, которые НАСТОЛЬКО жесткие, что они могут перестать тестировать таким образом, но не могут отрицать их существование ;-). В этом случае вас может спасти внедрение зависимостей — DI — один из моих любимых шаблонов для тестирования.

Цель DI при тестировании состоит в том, чтобы отделить тестируемый код от жестких предположений, которые препятствовали бы тестируемости — и это именно то, что мы имеем здесь, хотя и в необычной форме. Ваш тестируемый код в настоящее время выполняет, скажем, x.ErrorCode для получения кода ошибки исключения x. Очень хорошо, вместо этого он должен делать getErrorCode(x), где getErrorCode — делегат, который обычно просто выполняет return x.ErrorCode; и у него должен быть установщик для делегата getErrorCode, чтобы в целях тестирования вы могли изменить его на делегата, который выполняет return 23 (или любое другое значение кода ошибки, которое вы хотите имитировать для тестирования).

Детали могут различаться, но внедрение зависимостей может (среди прочего) помочь компенсировать некоторые виды чрезмерной жесткости в объектах, которые вы неизбежно получаете из системы (или из других библиотек и т. д., которые вы не можете напрямую изменять), как в этом примере.