File scope of a Unit Test

Question

I have a class Stats with a few methods in it. Like:

public int getAmountOfTimesAPlayerLogedIn(string playerName)

public int getHighestScoreInLeague ( string leagueName )

public int getTopPlayers ( string leagueName, int topResults )

When i create Unit Tests for this class, do i then have to create a separate .cs file for each method in this class?

Because i have a hard time naming my Unit Test methods. I like the WhenXXX_ThenYYY naming convention. But if i have one .cs file which covers all the method tests of Stats , then how do you really know what method it is testing?

I mean, suppose if i wanted to test getTopPlayers . Then I would create a Test Method like:

WhenLeageNameIsTest_Expect20

But how can you then tell what method is tested by looking at that name..? Could either be getHighestScoreInLeague or getTopPlayers .

So should i separate each test for a method in a separate .cs file? Or should i change my naming convention, or anything else?

Edit

This just occured to me. Is it ok to do multiple Asserts in one test method?

Answer 1

But how can you then tell what method is tested by looking at that name? ... Should I change my naming convention?

One popular convention is name your test methods in the form

 MethodUnderTest_Scenario_Expectation()

For you, if using that form, it would be

 public void getHighestScoreInLeague_LeagueNameIsTest_Returns20()

This is also a form recommended by Roy Osherove in The Art of Unit Testing . It allows you at a glance to know what is being tested and what is expected. You are most of the way there with your name, add the method name for that missing piece of clarity.

It is generally recommended to have one test file per class under test. If you have many methods you are testing, and you have many, many tests to cover the behaviors of these methods, perhaps it is an opportunity to evaluate your design. Is your class doing too much? That's not to say the answer is immediately "yes," it's just a thought that might need to be considered for a moment. When you keep your classes small on focused on single responsibilities, your tests (and test files) are naturally smaller as well.

---

This just occured to me. Is it ok to do multiple Asserts in one test method?

Ideally, no. You want a test to fail for one reason only. When you have multiple asserts, you have multiple reasons for failure. And if it is an early assert that fails, the subsequent asserts do not run. Isolate your asserts when possible.

Your unit tests should scream from the mountain top the specific scenario and expectation (via the name) and what went wrong (via the single Assert). You don't want to necessarily have to fire up the debugger to find out where a unit test failed, although it's not always avoidable.

Answer 2

There is a nice structure described here: http://haacked.com/archive/2012/01/01/structuring-unit-tests.aspx

Basically every method in your SUT has its own nested class in your fixture, then every test of that method is a testmethod. When combined they read almost as a sentence, eg TheTitleizerMethod.ReturnsDefaultTitleForNullName() . Code sample from the link:

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void ReturnsDefaultTitleForNullName()
        {
            // Test code
        }

        [Fact]
        public void AppendsTitleToName()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void ReturnsDefaultTitleForNullName()
        {
            // Test code
        }

        [Fact]
        public void AppendsSirToMaleNames()
        {
            // Test code
        }

        [Fact]
        public void AppendsDameToFemaleNames()
        {
            // Test code
        }
    }
}