Модульное тестирование системы SOA WCF, в которой трудно получить достойное покрытие

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

Модульные тесты не должны выходить за границы службы. На самом деле идея сервиса заключается в том, что он полностью независим и непрозрачен. Вы тестируете службу напрямую — не по каналу WCF, а путем модульного тестирования реальных классов, составляющих службу. После того, как вы протестировали саму службу (которую вы должны обеспечить почти 100%-ным охватом), вам не нужно задействовать ее в тестах на стороне клиента.

Для модульных тестов на стороне клиента вы издеваетесь над сервисом. WCF на самом деле делает это очень простым для вас, потому что каждый клиент WCF реализует интерфейс; если вы обычно используете FooService или FooServiceSoapClient в своем коде, измените его, чтобы использовать соответствующие IFooService или FooServiceSoap, которые реализует прокси-класс. Затем вы можете написать свой собственный MockFooService, реализующий тот же интерфейс, и использовать его в своих клиентских тестах.

Часть того, что иногда сбивает людей с толку, — это идея о том, что сервис может делать совершенно разные вещи в зависимости от конкретного сообщения. Тем не менее, клиентский тест, который включает интерфейс службы, обычно должен тестировать только одно или два конкретных сообщения на тест, поэтому легко смоделировать точный запрос/ответ, который вам нужен для данного клиентского теста, с помощью инструмента. например моки Rhino.

Дуплекс немного сложнее, но имейте в виду, что дуплексные сервисы также должны основываться на интерфейсах; даже пример MSDN представляет ICalculatorDuplexCallback. Обратные вызовы будут интерфейсами, поэтому так же, как вы можете смоделировать методы службы на стороне клиента, вы можете смоделировать обратные вызовы клиента на стороне службы. Просто используйте фиктивные/фальшивые обратные вызовы, которые вы используете для модульных тестов службы.

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

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

Например, код, тесно связанный со службой доступа к данным:

public class SomeSOA
{
 public bool DoSomeDataAccess()
 {
  //call the real data service
  DataService dataService = new DataService()
  int getANumber = dataService.GetANumber();
  return getANumber == 2;
 }
}

Небольшой рефакторинг, чтобы уменьшить связь с DataService.

public class SomeSOA
{
 IDataService _dataService;
 public SomeSOA(IDataService dataService)
{
  _dataService = dataService;
}
public SomeSOA() :this(new DataServiceWrapper()){}
 public bool DoSomeDataAccess()
 {
  int getANumber = _dataService.GetANumber();
  return getANumber == 2;
 }
}

public DataServiceWrapper : IDataService
{
  public int GetANumber()
  {
   // call the real data service
  }
}

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

[TestMethod]
public void GetANumber_WithAValidReturnedNumber_ReturnsTure()
{

  IDataService dataService = new DataServiceFake();
  SomeSOA someSoa = new SomeSOA(dataService);
  Assert.IsTrue(someSoa.DoSomeDataAccess();
}

public class DataServiceFake :IDataService
{
  public int DoSomeDataAccess()
  {
    //return a fake result from the dataService.
    return 2;
  }
}

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

Надеюсь, это поможет и имеет смысл!

Вот мое предложение: отойдите от парадигмы «модульного тестирования» и поработайте над набором интеграционных тестов.

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

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

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

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

Хотя они не являются «модульными тестами», вы получите полное покрытие.