TDD-使用属性自动生成代码

Question

I am practicing TDD using MsTest together with RhinoMocks, and I am trying to be as lazy as humanly possible, ie make use of VS2012 auto-generation wherever I can. But it doesn't always feel right to create an entire test method with the Arrange-Act-Assert methodology, just to set up my class and its constructors and properties.

Currently, I find it easiest to create some properties in my test class - even if I don't use them - solely for the purpose of code generation. My question is, is this a bad habit, and is there a better/easier way to do it? Any commentary, good or bad is welcome; Thank you!

[TestClass]
public class MainViewModelTest
{
    private MainViewModel MainViewModel
    {
        get
        {
            var facilityDataEntity = MockRepository.GenerateStub<FacilityDataEntity>();

            var viewModel = new MainViewModel(facilityDataEntity)
            {
                FacilityValue = string.Empty,
                FacilityLabel = string.Empty
            };

            return viewModel;
        }
    }

    private MainViewModel MainViewModelWithFacilityAndShopOrderData
    {
        get
        {
            var facilityDataEntity = MockRepository.GenerateStub<FacilityDataEntity>();
            var shopOrderDataEntity = MockRepository.GenerateStub<ShopOrderDataEntity>();

            var viewModel = new MainViewModel(facilityDataEntity, shopOrderDataEntity)
            {
                FacilityValue = string.Empty,
                FacilityLabel = string.Empty,
                ShopOrder = 99999999,
                RequiredQuantity = 0M,
                ItemCode = string.Empty,
                ItemDescription = string.Empty
            };

            return viewModel;
        }
    }

    [TestMethod]
    public void MainViewModel_TranslateDataEntityListMethodReturnsMainViewModelRecords()
    {
        // Arrange
        var facilityDataEntityList = MockRepository.GenerateStub<IEnumerable<FacilityDataEntity>>();
        var shopOrderDataEntityList = MockRepository.GenerateStub<IEnumerable<ShopOrderDataEntity>>();

        // Act
        IEnumerable<MainViewModel> facilityResults = MainViewModel.TranslateDataEntityList(facilityDataEntityList);
        IEnumerable<MainViewModel> shopOrderResults = MainViewModel.TranslateDataEntityList(facilityDataEntityList, shopOrderDataEntityList);

        // Assert
        Assert.IsInstanceOfType(facilityResults, typeof(IEnumerable<MainViewModel>));
        Assert.IsInstanceOfType(shopOrderResults, typeof(IEnumerable<MainViewModel>));
    }
}

Answer 1

It's not wrong to wrap up common code within your test classes, but I would avoid potentially sharing state between your tests.

There are two approaches you can use here.

Class/Test Initialization

As Peter mentions in his comments, it's easy enough to include initialization methods to do this sort of stuff for you.

//Only runs once per test run
[ClassInitialize]
public void InitClass(){

   //Ideally this should be reserved for expensive operations
   // or for setting properties that are static throughout
   // the lifetime of your test.

}

//Runs for every test
[TestInitialize]
public void TestInit(){

   //Here you can setup common stub/mock behavior
   // that will be common for every test, but ensure
   // it is clean for each test run

}

Setup/Factory Methods

Another option is to create specialized setup or factory methods that can be used to reduce repeated test code and make the intent of your test clearer.

[TestMethod]
public void ShouldFailIfUserNameIsTed(){

   var user = SetupUserScenario("Ted");

   var result = _myUserService.Validate(user);

   Assert.IsFalse(result);
}

private User SetupUserScenario(String username){

   var user = new User();
   user.Name = username;

   //Do a bunch of other necessary setup

   return user;
}

Hopefully this all makes sense, but I would also caution you not to go too crazy with this. If you put too much stuff into setup methods, then your tests will be less clear. You should be able to read the test and figure out what is going on without having to inspect a bunch of other places in the code.

Answer 2

That's what the ClassInitialize functionality is for. I would choose expected and recommended means of doing something before anything else. It's more easily recognizable and takes less time to grok the code.