Over the years I've struggled with naming conventions for unit test methods, picking up various habits from different projects and people.  Roy Osherove (who reminds me of Adam Sandler) at one point recommended the following format for your unit test names:

[MethodName_StateUnderTest_ExpectedBehavior]

Although workable, and certainly an improvement over chaos, I don't find it all that appealing.  Non-programmers probably won't get it, and even programmers might have to read it a couple of times - at least that's what I ran into.  It does organize a group of tests in a fixture nicely, but beyond that...  its just not for me.

I've tried varying other methods, but I've generally always started my test names with some sort of assertion like "Should" or "Can".  This makes the test at least state what the expected behavior that is supported in a semi-fluid way.

Beyond that I like my unit test method names to convey exactly what is being tested, not just the class or method name being tested along with a state - I want a full sentence describing the expected behavior.

Up until recently I've been following the .NET naming conventions for my unit tests, but the simple fact is my method names are too long to be readable sentences.  You see, my test method names tend to be sentences which may or may not come from the user story or task itself. 

Here's an example method name from my current project using the .NET naming conventions: ShouldRedirectToShippingPageWhenShippingIsRequiredAndShippingAddressIsMissing.  Not only is this long, but its also unreadable except to programmers.  Even to programmers this isn't pretty, its just too long.

Now here's how I've been formatting my test names as of recent:

Obviously I'm breaking .NET naming conventions left and right here, but I don't care who you are, that's waaaaay more readable. Even more importantly I can discern what the test does just by reading the method name.  I find this handier than reading comments since it also shows up in your test runner. 

There's little need to go back through and re-read the test itself to figure out what the test does, its clearly stated in the method name. With this style anyone can go back and read the unit test method name and figure out the expected behavior.

I've never been too happy with the .NET naming standards especially in regards to unit tests.  The world is bigger than .NET, so take that convention!