Как определить набор входных параметров в Pex? - PullRequest
Новая
       5

Как определить набор входных параметров в Pex?

2 голосов
/ 11 января 2012

Скажем, у меня есть MyClass с сотнями полей.

Если я использую объект MyClass в качестве входного параметра, Пекс просто захлебнется, пытаясь сгенерировать все возможные комбинации (моя работает на 1000 путей даже в простом тесте)

[PexMethod] void MytestMethod (параметр MyClass) {...}

Как я могу сказать Pex использовать только набор предопределенных объектов MyClass, а не пытаться быть умным и генерировать все возможные комбинации для тестирования?

Другими словами, я хочу вручную указать список возможных состояний для param в приведенном выше коде и указать Pex использовать его

Приветствия

Ответы [ 2 ]

2 голосов
/ 12 января 2012

Если вы обнаружите, что Pex генерирует большое количество нерелевантных, избыточных или иных бесполезных входных данных, вы можете сформировать значения, которые он генерирует для ввода ваших параметризованных модульных тестов, используя PexAssume, что обеспечит соответствие всех сгенерированных входных данных набор критериев, которые вы предоставляете.

Если вы хотите убедиться, что аргументы получены из предопределенной коллекции значений, например, вы можете сделать что-то вроде этого: 

public void TestSomething(Object a) {
    PexAssume.IsTrue(someCollection.Contains(a));
}

PexAssume имеет и другие вспомогательные методы для более общего сокращения ввода, такие как IsNotNull, AreNotEqual и т. Д. Из небольшого количества документации можно предположить, что есть также некоторые специфичные для коллекции функции, хотя если эти методы существуют, я не знаком с ними.

Ознакомьтесь с руководством Pex , чтобы получить немного больше информации.

0 голосов
/ 12 января 2012

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

if (MyObject.Property1 == "something")
{
    ...
}

тогда он попытается создать объект, имеющий Property1 == "something". Поэтому ограничение тестов некоторыми предопределенными объектами скорее противоречит «философии Pex». Тем не менее, вы можете найти следующую информацию интересной.

Вы можете предоставить заводской класс Pex. См., Например, это сообщение в блоге или это . 

[PexFactoryClass]  
public partial class EmployeeFactory  
{  
  [PexFactoryMethod(typeof(Employee))]  
  public static Employee Create(  
  int i0,  
  string s0,  
  string s1,  
  DateTime dt0,  
  DateTime dt1,  
  uint ui0,  
  Contract c0  
  )  
{  

  Employee e0 = new Employee();  
  e0.EmployeeID = i0;  
  e0.FirstName = s0;  
  e0.LastName = s1;  
  e0.BirthDate = dt0;  
  e0.StartDateContract = dt1;  
  e0.Salary = ui0;  
  e0.TypeContract = c0;  
  return e0;  
}

}

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

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

[PexArguments(1, "foo")] // try this first
void MyTest(int i, string s) 
{
    ...
}

См. здесь для получения дополнительной информации о PexArguments, а также поиска «начальных значений» в документации PDF на Параметризованные тестовые таблицы .

...