How to write mocks for foreach loops?

What are you trying to accomplish in your test? I'm not exactly following.

Although I'm not really getting what you're trying to mock exactly, but the extension methods I wrote will help - http://www.aaron-powell.com/blog/march- ... roids.aspx

They are designed to specify the number of times a certain mock will be "live" for, allowing you to specify when you want the loop to break out.

If you know exactly where in the HttpContext you want to mock you should just mock HttpContext (Isolate.Fake.Instance<HttpContext>()).

I've done HttpContext mocking, it's ok, but not super reliable. Here's a simple example:

var fakeContext = Isolate.Fake.Instance<HttpContext>();
Isolate.WhenCalled(() => HttpContext.Current).WillReturn(fakeContext);

Then just keep adding to it

For more clarification, the production code is:

public void MyMethod()
{

foreach (DataRow row in dataTable.Rows)
foreach (DataColumn column in dataTable.Columns)
HttpContext.Current.Response.Write(row[column.ColumnName].ToString());

}

How do you write a unit test for this method? we need to mock the bolded line, right? I asked how I can do that.

Please let me know if it's not clear yet.

Ben,

For the purpose of the test I think you should isolate the dependency in the data layer, and use a fake data collection. I don't know how you receive this data table in the code under test, but a complete test may look something like this:

// fake out any following call to Write() 
Isolate.WhenCalled(() => HttpContext.Current.Response.Write("")).IgnoreCall();

// prepare fake data structure to iterate over
var fakeTable = Isolate.Fake.Instance<DataTable>();
var fakeRow = Isolate.Fake.Instance<DataRow>();
var fakeColumn = Isolate.Fake.Instance<DataColumn>();
Isolate.WhenCalled(() => fakeColumn.ColumnName).WillReturn("TestColumn");
Isolate.WhenCalled(() => fakeRow["TestColumn")).WillReturn("TestOutput");

// make the Rows and Columns collections return our fake data
Isolate.WhenCalled(() => fakeTable.Rows).WillReturnCollectionValuesOf(new [] { fakeRow });
Isolate.WhenCalled(() => fakeTable. Columns).WillReturnCollectionValuesOf(new [] { fakeColumn });

// call the method under test with the fake data table
var target = new ClassUnderTest();
target.DoStuff(fakeTable);

// now verify the fake data has been accessed properly
Isolate.Verify.WasCalledWithExactArguments(() => HttpContext.Current.Response.Write("TestOutput"));

Let me know if this helps.

Thanks,
Doron
Typemock Support

Thanks Doron.

The dataTable is fine as I can pass to the MyMethod as input parameter.

Your comments inspired me to find the solution to my problem:

// mock HttpResponse
HttpResponse fakeHttpResponse = Isolate.Fake.Instance<HttpResponse>();
Isolate.WhenCalled <HttpResponse>(delegate() { return HttpContext.Current.Response; }).WillReturn(fakeHttpResponse);

// mock Response.Write()
Isolate.WhenCalled(delegate() { fakeHttpResponse.Write(""); }).IgnoreCall();

Then for verification:

foreach (DataRow row in dataTableForTest.Rows)
{
foreach (DataColumn column in dataTableForTest.Columns)
{
string toWrite = row[column.ColumnName].ToString() + ",";
Isolate.Verify.WasCalledWithExactArguments(
delegate() { fakeHttpResponse.Write(toWrite); });
}

}

The performance issue is resolved as well as it doesn't use the HttpContext.Current.Response.Write().

Lessons I learned:
1) At the time of mocking, we don't need to write the mocking statement several times if that dependency is used in the code several times e.g. my loop scenario

2) At the time of mocking, the input arguments don't matter. At the time of verification, we can verify the input arguments. Having said that this is in contrast with how NMock works as you can specify the expected method arguments when mocking using NMock. NMock syntax seems neater to me to be honest in this case. Maybe a feature for improvement for TypeMock?