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" <step...@littlevoices.com> 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
> <heinrichbre...@gmail.com> 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" <tree...@gmail.com> wrote:
>>> ClassForUseInheritsBaseClass
>>> On Mon, Jun 6, 2011 at 6:22 AM, Heinrich Breedt
>>> <heinrichbre...@gmail.com>wrote:
>>>
>>>> Just wondering, what is the name of the test?
>>>> On Jun 5, 2011 5:06 PM, "Tristan Reeves" <tree...@gmail.com> 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.
>>>>
>>
