1
\$\begingroup\$

I'm new to Rhino mock and I would like to know if the test I did is not fake testing, as I've read a lot about it. Are there any improvements that need to be done?

[Test]
public void GenerateDateTable_Returns_DataTableOfGroup()
{
    //Arrange
    var groupStub = MockRepository.GenerateStub<Group>();
    var groupEnumerable = new[] { groupStub };
    var mockgroup = MockRepository.GenerateMock<FillTableRow<Group>>();
    mockgroup.Replay();
    //Act
    mockgroup.GenerateDateTable(groupEnumerable);

    //Assert
    Assert.IsTrue(mockgroup.DataTableBatch.Columns.Count == 3);
}

public class FillTableRow<T>
{
    public DataTable DataTableBatch { get; set; }

    public DataTable GenerateDateTable(IEnumerable<T> enumerable)
    {
        IDbObjectFactory<T> tableFactory = new TableFactory<T>();
        DataTableBatch = (DataTable)tableFactory.GetDbObject();

        foreach (var row in enumerable)
        {
            AddRow(row);
        }
        return DataTableBatch;
    }
}
\$\endgroup\$
6
\$\begingroup\$

As far as I can understand (I use Moq as an isolation framework and not rhino mocks) in your test you are testing not an implementation of your class FillTableRow, but a mock, generated by isolation framework. You should always use your real class as systam under test (obviously). You use stubs to provide context in which your system under tests works, just to emulate the system's environment. And you use mocks if the state of your system under test is not changing during your test and you need to be sure that correct methods of external classes has been called. I recomend you to read "The Art of Unit Testing" book by Roy Osherove. It gives very good explanation of how and when you should use mocks and stubs.

\$\endgroup\$
3
\$\begingroup\$

You should introduce Dependency Injection so that FillTableRow<T> receives the object of type IDbObjectFactory<T> rather than instantiates it itself. Once you've done that you can write tests by injecting stub of IDbObjectFactory<T> into FillTableRow<T>.

In your current code there is no need in creating mock for FillTableRow<T> since it's the object under test, and you can instantiate it directly (you can use mock for object under test e.g. if you're testing abstract class). Also you may not need stub for Group object (it looks like a data object) if you can instantiate it with required configuration yourselves.

Fixed code for your current implementation:

[Test]
public void GenerateDateTable_Returns_DataTableOfGroup()
{
    //Arrange
    var groupEnumerable = new[] { new Group() };
    var sut = new FillTableRow<Group>();

    //Act
    var result = sut.GenerateDateTable(groupEnumerable);

    //Assert
    Assert.IsTrue(result.Columns.Count == 3); //I would also verify all 3 columns
}
\$\endgroup\$
  • 2
    \$\begingroup\$ @Maro - you would also benefit from doing this assert Assert.AreEqual(3, result.Columns.Count); instead. That way, if the count is something other than 3, the test failure would be expected 3, got 4 rather than expected true, got false which gives less context to the actual failure. \$\endgroup\$ – Trevor Pilley Apr 12 '13 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.