Как проверить параметры функции, если для теста важен только один параметр?

Question

У меня написан следующий тест:

[TestCase(null, 0, 0, null, null, ExpectedException = typeof(ArgumentNullException), TestName = "VerifyThat_WhenBeginWriteHasANullBuffer_AnArgumentNullExceptionIsThrown")]
[TestCase(new byte[] {1,2,3}, -1, 0, null, null, ExpectedException = typeof(ArgumentOutOfRangeException), TestName = "VerifyThat_WhenBeginWriteHasANegativeSizeParameter_AnArgumentOutOfRangeExceptionIsThrown")]
[TestCase(new byte[] { 1, 2, 3 }, 4, 0, null, null, ExpectedException = typeof(ArgumentOutOfRangeException), TestName = "VerifyThat_WhenBeginWriteHasASizeParameterThatIsBiggerThanTheBufferSizeAndTheOffsetIsZero_AnArgumentOutOfRangeExceptionIsThrown")]
[TestCase(new byte[] { 1, 2, 3 }, 5, 1, null, null, ExpectedException = typeof(ArgumentOutOfRangeException), TestName = "VerifyThat_WhenBeginWriteHasASizeParameterThatIsBiggerThanTheBufferSizeMinusTheOffset_AnArgumentOutOfRangeExceptionIsThrown")]
[TestCase(new byte[] { 1, 2, 3 }, 2, -1, null, null, ExpectedException = typeof(ArgumentOutOfRangeException), TestName = "VerifyThat_WhenBeginWriteHasANegativeOffsetParameter_AnArgumentOutOfRangeExceptionIsThrown")]
[TestCase(new byte[] { 1, 2, 3 }, 2, 5, null, null, ExpectedException = typeof(ArgumentOutOfRangeException), TestName = "VerifyThat_WhenBeginWriteHasAnOffsetParameterThatIsBiggerThanTheBufferSize_AnArgumentOutOfRangeExceptionIsThrown")]
public void VerifyThat_WhenBeginWritesGivenWrongParameters_AnExceptionIsThrown(byte[] buffer, int offset, int size, AsyncCallback callback, object state)
{
    connectedStream.BeginWrite(buffer, offset, size, callback, state);
}

В настоящее время я вызываю функцию BeginWrite с недопустимым параметром и случайными допустимыми параметрами.
Я правильно здесь поступаю? Есть ли лучший способ предоставить действительные параметры?

EDIT:
В этом случае достоверность тестируемого параметра зависит от действительных параметров.
Например, смещение недопустимо всякий раз, когда оно отрицательно или когда оно больше размера буфера минус смещение. Тот факт, что тест проходит в одном случае, когда смещение больше размера буфера за вычетом смещения или отрицательного значения, не доказывает, что метод всегда будет вызывать ArgumentOutOfRangeException. Я всегда могу что-то пропустить.
Всегда лучше проверить несколько входов, чем один раз.
Есть ли способ сделать это автоматически?

РЕДАКТИРОВАТЬ 2:
Может ли AutoFixture быть моим решением?

РЕДАКТИРОВАТЬ 3:
Автокрепление не имеет порта Silverlight.

Answer 1

Техническая часть.

В NUnit 2.5 есть несколько новых атрибутов, помогающих автоматизировать генерацию тестовых примеров:

• Range - создать несколько тестовых случаев, используя все числовые значения, указанные в диапазоне для параметра.
• Values - аналогично Range, где вместо числового диапазона можно указать список отдельных значений.
• ValueSource - укажите функцию для создания списка Values.
• TestCaseSoucre - укажите функцию для генерации списка TestCase. Каждая деталь может быть настроена.

Range, Values и ValueSource применяются к одному параметру. Каждый параметр может использовать свой собственный атрибут значения.

Функция, используемая для ValueSource и TestCaseSource, вызывается очень рано, вероятно до TestFixtureSetUp. Обратитесь к документации для использования.

Пример.

• Массив байтов buffer может использовать функцию ValueSource, которая задает размер буфера, так что вы можете использовать большие массивы, не слишком много печатая.
• Для данного buffer допустимый диапазон для size составляет от 1 до размера буфера.
• Для заданных buffer и size допустимый диапазон для offset составляет от нуля до размера минус размер (я оставлю это для вас; это последовательный диапазон)
• Все остальное вне диапазона.

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

---

Часть философии теста.

• Если вам известны несколько подходов к тестированию (или критерии), всегда принимайте их все, и в рамках каждого подхода используйте разумный набор тестовых случаев.
• Используйте автоматическую генерацию тестовых наборов для максимальной выгоды.
• Без доступа к исходному коду (тестируемого программного обеспечения) и зная охват нашего тестового кода, мы не можем решить, что мы что-то упустили. Вот почему тестирование белого ящика необходимо, если требуется определенный уровень гарантии.

Answer 2

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

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

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