Using parameterized tests with "ExpectedResult" and following Osherove's 3-part naming convention
<p>I really like Roy Osherove's 3-part naming convention for naming unit tests:  </p>

<blockquote>
  <p>[UnitOfWork_StateUnderTest_ExpectedBehavior]</p>
</blockquote>

<p>Which to me means something like this (even when using parameterized inputs):</p>

<pre><code>[TestCase("user1")]
[TestCase("user2")]
public void SayHello_OnExistingUser_ReturnsHelloMessage(string username) 
{
    Assert.AreEqual("Hello " + username, SayHello(username));
}

[TestCase("badusername")]
[TestCase("")]
public void SayHello_OnNonExistingUser_ReturnsNull(string username) 
{
    Assert.IsNull(SayHello(username));
}
</code></pre>

<p>However, this is a bit tricky when using parameterized unit tests <strong>with specified expected result per test case</strong>, such as:</p>

<pre><code>[TestCase("user1", ExpectedResult = "Hello user1")]
[TestCase("user2", ExpectedResult = "Hello user2")]
[TestCase("badusername", ExpectedResult = null)]
[TestCase("", ExpectedResult = null)]
public void TESTNAMEHERE(string username)
{
    return SayHello(username);
}
</code></pre>

<p>With parameters for both the <em>StateUnderTest</em> and <em>ExpectedBehavior</em> it is less obvious what the test name should be.  I have heard suggestions to NOT use the "expected result" in TestCase for this reason, but it seems like a potentially great functionality that could simplify the test code.</p>

<p>I'd like to hear some suggestions for how to do this.  Abandon ExpectedResult for the sake of unit test naming clarity?  Or trade some clarity for test code brevity?</p>