Unit tests should be designed so that:
They set up some state
They run the method under test
They assert that one thing is correct after the method under test has completed
(reference: The Art of Unit Testing by Roy Osherove)
Why are tests that are designed to fail a bad thing? They could fail in unexpected ways, and still be marked as a pass because they failed. In your example, assuming that Should() is the method under test (though this point remains even if it isn't), you write the test above and mark it as 'expected to fail'. It fails. Everything is fine. In a couple of months you come back to Should() and realise it needs some refactoring, so you change its implementation.
Now, in your example, Should() throws an exception, because you've accidentally introduced a bug. But your test (which fails because of the exception now, not the logic) is marked as should fail, and it does, so it's still marked as a pass, despite the breaking change.
The test should be designed to pass, not to fail, that way if it fails in another, unexpected, way you'll be notified. So in your example you should write tests with opposite logic:
[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>();
}
(Not sure of the syntax you're using, so .Not probably will need replacing with the correct syntax, but the sentiment holds).
Edit2: If what you're trying to do is ensure that your Should() method fails (by failing an Assert. method) then what you want to do is catch the NUnit AssertionException which the Assert. static methods throw. Try this:
[Test]
[ExpectedException(typeof(AssertionException))]
public void ShouldBeTypeOf_WithInt_Fails() {
string str = "abc";
str.Should().Be.TypeOf<int>();
}