Изменение контекста сборки в MStest - можно избежать?

Question

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

Мы неявно используем _getDefaultName из Microsoft.Practices.EnterpriseLibrary.Data , и он получает строку подключения по умолчанию в текущей сборке *1006* App.config текущей сборки. Поскольку этот тестовый проект будет новой сборкой / проектом, он не сможет найти строку подключения в исходном проекте.

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

Но я не хочу менять исходный код ради тестового кода, так есть ли способ указать или изменить текущую работающую сборку?

Будет ли моя жизнь простой, если я использую какой-либо другой фреймворк для тестирования?

Answer 1

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

    public static class Context
    {
        private static string ConnectString;

        public static string Connect
        {
            get { return ConnectString ?? DataFactory.instance; }
            set { ConnectString= value; }
        }

        private class DataFactory
        {
            static DataFactory() { }
            internal static readonly string instance
                   = EntLib.Data._getDefaultName;
        }
    } 

Теперь, когда рабочий код запускается, он получает свою конфигурацию из EntLib - из файла App.Config. Но когда вы запускаете код mstest, убедитесь, что нужная строка подключения вставлена ​​в Context.Connect до того, как будет протестирована любая часть сборки.

Answer 2

Что ж, ваша жизнь могла бы быть проще, если бы вы использовали другие платформы тестирования;) (я использую и люблю NUnit ), но это вряд ли решит эту проблему.

Я бы предложил просто скопировать данные App.config в сборку модульного теста. Возможно, вы захотите изменить его, поскольку, по-видимому, вы не хотите, чтобы ваши тесты работали с производственной базой данных.

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