views:

55

answers:

2

I currently am using the following bit of code to initialize some Unit-Tests in a class:

[TestClass]
public class BoardTests_SquarePieceFalling
{
    private Engine engine;
    private BackgroundBoard backgroundBoard;
    private PieceBoard pieceBoard;

    private IFallingPieceFactory GetFallingPieceFactory(FallingPiece fallingPieceToReturn)
    {
        var factory = new Mock<IFallingPieceFactory>();
        factory.Setup(f => f.Generate()).Returns(fallingPieceToReturn);
        return factory.Object;
    }

    private void TestInitializer(Color pieceColor, Size boardSize) {
        backgroundBoard = new BackgroundBoard(boardSize);
        pieceBoard = new PieceBoard(boardSize);

        var fallingPiece = new FallingPiece(new SquarePiece(), pieceColor, boardSize.Width);
        var fallingPieceFactory = GetFallingPieceFactory(fallingPiece);
        var currentFallingPiece = new CurrentFallingPiece(fallingPieceFactory);
        var fallingPieceMovementEvaluator = new FallingPieceMovementEvaluator(backgroundBoard, currentFallingPiece, boardSize);

        engine = new Engine(backgroundBoard, pieceBoard, currentFallingPiece, fallingPieceMovementEvaluator);
    }

    ...Unit-Tests are below

    [TestMethod]
    public void When_Square_Hits_The_Ground_Another_One_Starts_Falling_From_The_Top()
    {
        TestInitializer(Color.Red, new Size(2, 7));

        engine.Tick(10);

        ..Asserts..
    }

    ...
}

Now, I think I currently have way too many test methods on this class. I also believe they cover a lot of ground, so I'd like to divide them in smaller test classes.

My questions are:

  1. Currently, is this the best way to initialize the tests? I know I can use [TestInitialize] annotation, but that doesn't allow me to pass parameters to the initialization of the fields I'll want to use, does it?

  2. I am going to split the current test class in 2-3 smaller test classes. My current idea is to create a base test class where the initialization logic resides, and then make all these new classes inherit from it. The only difference I'm seeing is having to put Engine, BackgroundBoard and PieceBoard as protected fields. Is this a good idea?

  3. How do you generally take care of Unit-Tests that are very similar, but that generally have always at least 1 different setup field? I mean, in a lot of my Unit-Tests I have the same Engine, BackgroundBoard, PieceBoard, FallingPiece, CurrentFallingPiece, FallingPieceFactory, etc, etc, but generally one or two of those things are different for each test. I circumvented the problem by defining the TestInitializer() method with the parameters I need in each test, but I am left wondering if there is any other way to do this.

Thanks

+1  A: 

Generally, it's clearest to have one test class (file) per class being tested.

So you should have a EngineTest, BackgroundBoardTest, etc.

matt b
+1  A: 

I don't see any problems with what you're doing. You might want to check this out: http://xunitpatterns.com/Parameterized%20Test.html

Frank Schwieterman