как вы указываете, что тест NUnit должен завершиться неудачей?

Как насчет Assert.Throws‹XXXException›(x.DoSomething());

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

Учитывая, что в этом случае вы хотите протестировать расширения NUnit, которые, как я предполагаю, функционируют, выполняя вызовы Assert, вы можете использовать Assert.Throws‹AssertionException›(...), а затем выполнить описанное выше.

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

Модульные тесты должны быть разработаны таким образом, чтобы:
они устанавливали некоторое состояние
они запускали тестируемый метод
они утверждали, что одна вещь верна после завершения тестируемого метода

(ссылка: Искусство модульного тестирования Роя Ошерова)

Почему тесты, рассчитанные на провал, — это плохо? Они могут потерпеть неудачу неожиданным образом и все равно будут помечены как пройденные, потому что они не прошли. В вашем примере, предполагая, что Should() является тестируемым методом (хотя этот пункт остается, даже если это не так), вы пишете тест выше и помечаете его как «ожидаемый сбой». Это терпит неудачу. Все отлично. Через пару месяцев вы возвращаетесь к Should() и понимаете, что он нуждается в некотором рефакторинге, поэтому вы меняете его реализацию.

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

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

[Test]
public void TypeOf_ShouldBeString() {
    string str = "abc";
    str.Should().Be.TypeOf<string>();
}

or:

[Test]
public void TypeOf_ShouldNotBeInt() {
    string str = "abc";
    str.Should().Not.Be.TypeOf<int>();
}

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

Edit2: Если то, что вы пытаетесь сделать, это убедиться, что ваш метод Should() не работает (путем отказа метода Assert.), то вам нужно поймать исключение NUnit AssertionException, которое Assert. статические методы бросают. Попробуй это:

[Test]
[ExpectedException(typeof(AssertionException))]
public void ShouldBeTypeOf_WithInt_Fails() {
    string str = "abc";
    str.Should().Be.TypeOf<int>();
}    

Я знаю, что это старый пост, но вот что мне помогло, используя NUnit:

[TestCase("SomeValidValue")]
[TestCase("{3X5XFX9X-7XCX-4XCX-8X3X-3XAXEX9X0XBX}", ExpectedException = typeof(AssertionException))]
public void GetSpecificConfiguration(string key)
{
    Assert.IsNotNull(Config.Instance.GetRecord(key));
}

Этот подход позволяет мне провести один и тот же тест с двумя ожиданиями, одним успешным и одним неудачным.

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

[Test]
[ExpectedException(typeof(Exception))]
public void TypeOf_fail() {
    string str = "abc";
    str.Should().Be.TypeOf<int>();
}

Конечно, замените Exception наиболее конкретным возможным исключением.