Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Unit testing - stubbing an SqlDataReader

We have an n-tier web application that pulls data from SQL Server. Our Data Access logic returns an SqlDataReader whose data is then used to create our Business objects (a.k.a. Data Transfer objects).

We wish to build unit tests to check our code that interprets the data returned by these SqlDataReader objects to build our Business objects.

It therefore seems necessary to build stubs to replace the SqlDataReader objects during unit testing. As is probably fairly typical, our SqlDataReader objects generally return multiple recordsets, each with multiple rows.

  1. Is this a sensible endeavour?
  2. How should we go about building these stub objects?

Many thanks in advance

Griff

like image 960
DrGriff Avatar asked Mar 28 '12 13:03

DrGriff


People also ask

What is stubbing in unit testing?

A stub is a small piece of code that takes the place of another component during testing. The benefit of using a stub is that it returns consistent results, making the test easier to write. And you can run tests even if the other components are not working yet.

Which method provides SqlDataReader object from SqlCommand object?

To create a SqlDataReader, you must call the ExecuteReader method of the SqlCommand object, instead of directly using a constructor. While the SqlDataReader is being used, the associated SqlConnection is busy serving the SqlDataReader, and no other operations can be performed on the SqlConnection other than closing it.

What is SqlDataReader?

The SqlDataReader is used to read a row of record at a time which is got using SqlCommand. It is read only, which means we can only read the record; it can not be edited. And also it is forward only, which means you can not go back to a previous row (record).

What is SqlDataReader in Ado net?

ADO.NET SqlDataReader Class. This class is used to read data from SQL Server database. It reads data in forward-only stream of rows from a SQL Server database. it is sealed class so that cannot be inherited.


1 Answers

Automated testing is basically always a sensible endeavour :)

Your first step to be able to test this is to have your Data Access logic return an IDataReader instead of an SqlDataReader - SqlDataReader implements IDataReader, so no problems there.

In your unit tests you can then manually build and populate DataTable objects, and call dataTable.CreateDataReader() to get an IDataReader to pass into the object under test.

Edit

To provide your tests with a set of sample data, I'd suggest using an ObjectMother for each data table you use, keeping creation of the data tables in one dedicated place. You can then put methods on each ObjectMethod class to update certain data in a strongly-typed way. For example:

public class PersonalDetailsBuilder
{
    private DataTable _dataTable;

    public PersonalDetailsBuilder CreateNewTable()
    {
        this._dataTable = new DataTable("CustomerPersonalDetails")
        {
            Columns = 
            {
                new DataColumn("CustomerId", typeof(int)),
                new DataColumn("CustomerName", typeof(string))
            }
        };

        return this;
    }

    public PersonalDetailsBuilder AddStandardData(int numberOfRows = 3)
    {
        foreach (int i in Enumerable.Range(1, numberOfRows + 1))
        {
            this.AddRow(i, "Customer " + i);
        }

        return this;
    }

    public PersonalDetailsBuilder AddRow(int customerId, string customerName)
    {
        this._dataTable.Rows.Add(customerId, customerName);

        return this;
    }

    public IDataReader ToDataReader()
    {
        return this._dataTable.CreateDataReader();
    }
}

...which you could then use like this to get a data reader:

IDataReader customerDetailsReader = new PersonalDetailsBuilder()
    .CreateNewTable()
    .AddStandardData()
    .AddRow(17, "Customer 17")
    .ToDataReader();
like image 106
Steve Wilkes Avatar answered Sep 28 '22 22:09

Steve Wilkes