Интеграционное тестирование веб-сервисов с тестовой базой данных

Question

В настоящее время я создаю веб-приложение .net, которое использует веб-сервисы WCF, чтобы позволить внешнему интерфейсу Flex получать доступ к базе данных.

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

В настоящее время строка подключения в моем проекте модульных тестов указывает на мою тестовую базу данных,и строка подключения в моем проекте веб-служб указывает на мою базу данных разработки.Однако, поскольку я использую Linq, кажется, что когда я вызываю методы веб-службы из моего тестового класса, он использует строку подключения к базе данных разработки.

Я изучил создание фиктивных объектов или базы данных в памяти, но яполагаю, что возникнет та же проблема.

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

Answer 1

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

Я успешно достиг этого в автоматических тестах для моего проекта.

Обратите внимание, что клиент WCF и хост WCF могут совместно использовать один и тот же процесс. В этом случае он все еще выполняет вызовы через инфраструктуру WCF со всеми ограничениями и сложностями. А ваши сервисы WCF извлекут строку подключения из файла конфигурации вашего тестового проекта.

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

<configuration>
  <connectionStrings>
    <add name="ContractsManager" 
         providerName="System.Data.SqlClient" 
         connectionString="Data Source=localhost;Initial Catalog=ContractsManager_AutoTest;Integrated Security=True;Pooling=False;Asynchronous Processing=true;Application Name=CmAutoTests"
         />
  </connectionStrings>
    <system.serviceModel>

        <client>
            <endpoint
                name="LoggingService"
                address="net.tcp://localhost:9612/loggingService"
                binding="netTcpBinding"
                contract="ContractsManager.ILoginService" />
        </client>
        <services>
            <service name="ContractsManager.LoginServiceImpl">
                <endpoint
                    address="net.tcp://localhost:9612/loggingService"
                    binding="netTcpBinding"
                    contract="ContractsManager.ILoginService">
                </endpoint>
            </service>
        </services>
    </system.serviceModel>
</configuration>

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

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

Удачи.

Answer 2

Убедитесь, что код в веб-сервисе минимален и не намного больше, чем простой вызов уровня вашего сервиса. Когда вы это сделаете, вы можете пропустить вызов веб-службы напрямую и создать набор интеграционных тестов, который также вызывает уровень вашего сервиса. В этом случае вы выполняете внутрипроцессный вызов вместо вызова по сети. В такой ситуации будет гораздо проще обеспечить доступ к нужной базе данных, и вы сможете легко обернуть эти вызовы транзакциями базы данных, которые будут откатываться. Вы, конечно, хотите откатить любые действия с базой данных, потому что будет очень трудно поддерживать RTM тесты . Один из способов сделать это - использовать TransactionScope внутри тестов.

Удачи.

Answer 3

Поскольку класс веб-службы WCF не связан с инфраструктурой ASP.Net (не нужно наследовать от Syste.Web.Services.WebService), вы можете легко вставить ссылку на хранилище или контекст объекта в оказание услуг. Затем вы можете проверить любую логику в самом веб-сервисе, используя модульные тесты, которые будут использовать какой-то фиктивный репозиторий в памяти и, следовательно, работать очень быстро. С другой стороны, интеграционные тесты будут использовать некоторую реальную базу данных, и вы можете обнаружить ошибки, связанные с уровнем персистентности. Поэтому я не согласен со Стивеном в том, что методы веб-службы должны быть однострочными и вызывать некоторый уровень службы, если только логика не настолько тяжелая, что заслуживает своего собственного класса (классов).