Refactoring has become a common practice amongst many developers I work with. Why refactor?
Well, first it takes the pressure of off design phase of project in a sense. You do not have spend ton of time upfront designing the code and assuring that you thought of every detail before you even write a single line of code. You simply get a rough design and start coding right away, knowing that as you implement the system, get more familiar with the code, you will notice better patterns and refactor the code towards them.
We all know that, if done right, refactoring leads to simpler smaller code base that is easier to maintain. Meantime we use Unit Tests to assure that the refactoring we performed did not change the outcome or results that our code produces. I have been following this practice for a while and it has kept me out of trouble.
However what I realized over time is that the Unit Tests themselves become more complex, with too much duplication, and too hard to read.
Take for example this problem I had recently at the client I am working for. We inherited a “failed” project (story of my life – I always end up coming in to fix someone else’s mess, but enough about that), a project that another consulting company has given up on after complicating the matter a bit first.
No, they did not use code refactoring, they did not have unit tests, instead they have used code generation tool to “save time”. It is just that their code generation templates were not really thought through. Now we have a complex system, with a lot of bugs to clean and lot of code to refactor. And yes, in order to refactor we had to start writing unit tests to support it.
Well all of their Business Objects are initialized by making a DB call in their constructor that uses Datasets as the DTOs that transfer that data from the DAL (I know what you are going to say now – but sometimes you have to work with what you have – we have to bring this site online!).
But lets start with an example. Lets say I had a bussiness object called ShoppingCart and that it contained a list Product sand a list of Options for eaach product. In the constructor of the ShoppingCart, they would have an instance of a ShoppingCartData object that would have a method callled ExecuteDataSet() which although the name does not state it returns all Products and their options that belong to this shopping cart. Then the code inside of the dataset woule lop through the tables and populate both object lists, something like:
ShoppingCartData _shoppingCartData = new ShoppingCartData();
public ShoppingCart()
{
DataSet ds = _shoppingCartData.ExecuteDataSet();
foreach(DataRowView in ds.Tables[0].Rows){
…
}
So in order to write tests against these objects I had to mock the DAL call and replace the DataSet that the DB would return with my own. As you can see ShoppingCartData was not injected, nor did it have an interface so for mocking part I had to bring the big guns – TypeMock.
Mock data = MockManager.Mock(typeof(ShoppingCartData));
cartData.ExpectAndReturn("ExecuteDataSet",cartDataSetStub);
So mocking the Db call and taking DB out of eqation was easy. Even generating the stub data for the tests was not the problem. You might have read one of my previos blogs where I wrote about this little code generation tool that helped me generate DataTable Stub objects just by runnig the sql :
http://www.nermins.net/post/2007/07/Mock-ADONET-with-ease-using-IDataReader-Stub-objects.aspx
In that previous example I take advantage of DataTable CreateReader() method to generate IDataReader Stubs. However in this case my Stub objects are DataSets, so I can use these table Stubs directly.
I also have the code for that tool available on the google code site:
http://code.google.com/p/data-stub-generator/
So, if setting up mocking and setting up Stub data was not the problem then what was? I had to write a number of tests against each of the BO including Shopping Cart. That meant setting up the data for the cartTadaSetsTub DataSet. I also wanted my code genaration tool to generate tables with one and couple of tests records that represent the dafault /valid data, and then explicitly set the values/cells that were needed for the test in the test itself.
For example let’s say that we have the rule that says that shopping cart can not check out if there is at least on item that has been discontinued since we placed it on the shopping cart. That means that my table returning Products data would have to have one record that has “Discountinued” column set to true. So let’s take a look at the code needeed for that:
DataSet cartDataSetStub = new DataSet();
DataTable products = new ShoppingCartProductsStub();
products.AddDefaultRow();
products.Rows[0][“Discountinued”] = true;
DataTable options = new ShoppingCartOptionsStub();
cartDataSetStub.Tables.Add(products);
cartDataSetStub.Tables.Add(options);
Mock cartData = MockManager.Mock(typeof(ShoppingCartData));
//Assure that _shoppingCartData.ExecuteDataSet()
//returns our cartDataSetStub instead of calling DB
cartData.ExpectAndReturn("ExecuteDataSet",cartDataSetStub);
ShoppingCart cart = new ShoppingCart();
Assert.That(cart.CanCheckOut, Is.EqualTo(false));
First 7 lines of code are there just to simply setup “fake” output from the database. There is more code in the part that sets up the data for the test than the actual test. And actually it could have been worse if I have not used the generated table stub objects ShoppingCartProductsStub and ShoppingCartOptionsStub. All that code crowds the test and doesn’t really expresss my intention – it is hard to read. So what did I do to solve that?
Fluent Interfaces to the rescue! How about this for a change:
Mock cartData = MockManager.Mock(typeof(ShoppingCartData));
cartData.ExpectAndReturn(
"ExecuteDataSet",
Stub.GetDataSet(
ShoppingCartProductsStub.Empty().AddDefaultRow()
.AtRow(0)
.InCell(“Discountinued”)
.SetValue(true),
ShoppingCartOptionsStub.Empty()));
ShoppingCart cart = new ShoppingCart();
Assert.That(cart.CanCheckOut, Is.EqualTo(false));
Four statements above are functionaly equivalent to that code mesh in previous example. And as you can see you can simply read the code to figure what it does! We are generating DataSet with two tables where on the first table we add the default row of data and then set the cell “Discontinued” to false. Second table is empty. And that is it.
So how do these fluent interfaces work? What is the logic behind them? Well simply put, lest take a look at the methods that we use to manipulate an object (StubTable in this case). In the example above those methods are: Empty(), AddDefaultRow(), AtRow(int rowNo), InCell(string cellName), SetValue(object value). Generaly these methods would return void. In fluent programing they return the object itself or better an interface that implements these other methods. So first I created the object called StubTable:
public class StubTable : DataTable
{
private int _currRow = 0;
private string _currCell = string.Empty;
protected StubTable(){}
public static StubTable Empty()
{
return new StubTable();
}
public StubTable AtRow(int rowNo)
{
_currRow = rowNo;
return this;
}
public StubTable InCell(string cellName)
{
_currCell = cellName;
return this;
}
public StubTable SetValue(object value)
{
Rows[_currRow][_currCell] = value;
return this;
}
public StubTable AddRow(params object[] values)
{
Rows.Add(values);
return this;
}
}
Then the generated SoppingCartProducts and ShoppingCartOptions DataTables inherit from Stub table and are modified to look like this:
public class ShoppingCartProductsStub : StubTable
{
public new static ShoppingCartProductsStub Empty()
{
return new ShoppingCartProductsStub();
}
protected ShoppingCartProductsStub()
{
InitColumns();
}
private void InitColumns()
{
Columns.Add("ShopingCartID", typeof(Int32));
Columns.Add("ProductID", typeof(Int32));
Columns.Add("ProductName", typeof(String));
Columns.Add("ProductNumber", typeof(String));
Columns.Add("ProductQty", typeof(Int32));
Columns.Add("Price", typeof(Decimal));
Columns.Add("PromotionPrice", typeof(Decimal));
Columns.Add("Discontinued", typeof(Boolean));
…
}
public StubTable AddDefaultProduct()
{
Rows.Add(705582, 1, "Round Cook-N-Dine Built-in Cook Top", "MO-60", 5,
decimal.Parse("1200.9400000000000"), decimal.Parse("1200.9400000000000"),false);
return this;
}
}
And Finaly Our Stb class that builds and returns the DataSet DTO:
public class Stub
{
public static DataSet GetDataSet(params DataTable[] tables)
{
DataSet ds = new DataSet();
foreach (DataTable table in tables)
ds.Tables.Add(table);
return ds;
}
}
The conclusion I would draw from this is that with a little thinking upfront, and a little refactoring we can make our tests a lot more readable. We always have to keep in mind that our tests might be the first thing that the next developer is going to look at. Making the test little bit more readible helps them figure out easier on how the actual object being tested is used and what are the expectations set for it.
