Опасно использовать переменные класса Scoped в TestMethods

Question

Опасно использовать переменные класса Scoped в TestMethods

1

Я новичок в тестировании MOQ и TDD/Unit. Я нахожу, что повторяю много одного и того же кода в разделе "Упорядочить" каждого метода тестирования, и кажется, что это действительно должно быть лучшим способом.

Сначала код, который часто повторяется:

#region Arrange

    #region create my Mock Objects

        var serviceMock = new Mock<IOrganizationService>();
        var factoryMock = new Mock<IOrganizationServiceFactory>();
        var tracingServiceMock = new Mock<ITracingService>();
        var notificationServiceMock = new Mock<IServiceEndpointNotificationService>();
        var pluginContextMock = new Mock<IPluginExecutionContext>();
        var serviceProviderMock = new Mock<IServiceProvider>();

    #endregion

    #region Authentication Stuff

        var organizationUri = "http://.../XRMServices/2011/Organization.svc";
        var orgServiceManagement = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(new Uri(organizationUri));
        var credentials = new AuthenticationCredentials();
        var username = "USER_ID";
        var password = "USER_PWD";
        var domain = "MyDomain";
        credentials.ClientCredentials. Windows.ClientCredential = new NetworkCredential(username, password, domain);
        IOrganizationService service = new OrganizationServiceProxy(orgServiceManagement, credentials.ClientCredentials);

    #endregion

#endregion

Я рассматривал возможность создания пользовательских фрагментов, констант и т.д., Но это не спасет повторяющийся код, просто избавит меня от некорректного ввода текста.

Затем я подумал о том, чтобы просмотреть все выше на уровне класса... но некоторые предупреждающие колокола исчезли... Если класс создает экземпляр один раз для всех методов тестирования, то может ли быть возможность переменного загрязнения? Учитывая, что в маленьком образце здесь это действительно не произойдет, я пытаюсь думать вперед/развивать хорошие практики и привычки.

Как насчет создания объекта "Mock & Authentication", который имел все это в этом объекте. Тогда я мог бы иметь несколько из этих объектов с разными учетными данными, и мои методы тестирования могли бы ссылаться/использовать только одну вариацию?

Итак, каковы будут ваши рекомендации/рекомендации по применению некоторых СУХИХ принципов для моих тестовых случаев.

GPGVM 21 июль 2014, в 19:46

Источник

Теги:

c#

unit-testing

moq

moq-3

1 ответ

Ещё вопросы

k.m · Accepted Answer · 2014-07-21T18-03-00.000Z

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

Затем я подумал о том, чтобы просмотреть все выше на уровне класса... но некоторые предупреждающие колокола исчезли... Если класс создает экземпляр один раз для всех методов тестирования, то может ли быть возможность переменного загрязнения?

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

В NUnit вы получили [SetUp] (MS Test использует [TestInitialize] а xUnit использует конструктор классов):

[SetUp]
public void InitializeDependencies()
{  
    serviceMock = new Mock<IOrganizationService>();
    // ...
}

Так вы обычно решаете такие проблемы.

Как насчет создания объекта "Mock & Authentication", который имел все это в этом объекте.

Хотя это может быть хорошей идеей для части аутентификации, это, конечно, не так звучит для насмешек. Тот факт, что вы даже считаете, что он снова звонит на рефакторинг-колокола.

Спасибо Большое. Я поменял направление / совет, который вы предоставили. Это помогло сократить огромное количество повторяющегося кода, а также повысить производительность.