The biggest benefit of proper test naming is that it forces you to think
what you are testing. IMHO of course.
Resharper allows you to have multiple naming styles.
On Jun 6, 2011 1:35 PM, "Stephen Price" <[email protected]> wrote:
> I follow the suggested naming from The Art of Unit testing by Roy
Osherove.
>
> MethodBeingTested_Inputs_ExpectedResult
>
> ie:
>
> Constructor_PassInDependencies_IsNotNull
> CreateInstance_PassValidJobId_CreatesInstance
>
> or whatever. I just make it up as I go along, but by following the
> three part template you can tell from the name what is being tested,
> what the inputs are and what the expected output is. The thing you are
> testing is a black box and that naming tells you all you need to know
> about the test, it shouldn't be doing anything else. I group the tests
> per class being tested.
>
> The only annoying thing about this naming is that you have to ignore
> Resharper's default naming rules. It doesnt like the underscores. I
> must sit down and figure out if there's a way to modify the rules to
> allow underscores for unit tests. Anyone done this?
>
> cheers,
> Stephen
>
> On Mon, Jun 6, 2011 at 10:42 AM, Heinrich Breedt
> <[email protected]> wrote:
>> As an exercise, try making the method name articulate what you are
testing.
>> Use underscore for space. Don't be afraid to use longish sentence
>>
>> On Jun 6, 2011 12:32 PM, "Tristan Reeves" <[email protected]> wrote:
>>> ClassForUseInheritsBaseClass
>>> On Mon, Jun 6, 2011 at 6:22 AM, Heinrich Breedt
>>> <[email protected]>wrote:
>>>
>>>> Just wondering, what is the name of the test?
>>>> On Jun 5, 2011 5:06 PM, "Tristan Reeves" <[email protected]> wrote:
>>>> > Hi list,
>>>> > I'll describe the situation in as little detail as possible.
>>>> >
>>>> > There's some code in which a class BaseClass, and a class ClassForUse
:
>>>> > BaseClass are defined.
>>>> >
>>>> > BaseClass is used in a unit test that calls its constructor with
mocks.
>>>> > ClassForUse is used in production with a 0-param constructor which
>>>> > calls
>>>> the
>>>> > base constructor with hard-coded arguments.
>>>> >
>>>> > Forgetting (for now) any issues with all this (and to me there are
>>>> plenty),
>>>> > we then find the following unit test:
>>>> >
>>>> > [Setup]
>>>> > var _instance = new ClassForUse();
>>>> >
>>>> > [Test]
>>>> > Assert.That(_instance is BaseClass);
>>>> >
>>>> > ...to me this is totally insane. But I seem unable to articulate
>>>> > exactly
>>>> the
>>>> > nature of the insanity.
>>>> >
>>>> > A little further on we have (pseudocode)
>>>> > [Test]
>>>> > Assert _instance._MemberOne is of type A
>>>> > Assert _instance._MemberTwo is of type B
>>>> > Assert _instance._MemberThree is of type C
>>>> >
>>>> > where the members are (if not for the tests) private members set by
the
>>>> > 0-param constructor which pushed them into the base constructor. (all
>>>> hard
>>>> > coded).
>>>> >
>>>> > So...is this really insane, or is it I who am crazy?? It's made more
>>>> > perplexing to me because the author of this code says it's all a
>>>> > natural
>>>> > result of TDD. And I am far from a TDD expert.
>>>> >
>>>> > I would love some feedback about this Modus Operandi. esp. any refs.
It
>>>> > seems obviously wrong, and yet I am unable to come up with any
>>>> > definitive
>>>> > argument.
>>>> >
>>>> > Thanks,
>>>> > Tristan.
>>>>
>>
