Mocking Linq – Preview

Eli Lopian    Product    

We are working on our .NET 3.5 Support. There are many new feature that have been added, we will take a look at how to mock a linq statement

For the following code in our application

Northwind db = new Northwind(connStr) ;
var query = from c in db.Customers
where c.City == "Sarasota"
select new { c.Name, c.City };

Here is how to mock this statement and return fake customers

[TestMethod]
[VerifyMocks]
public void IsolateLinq()
{
// create fake return values
    var fake = new[] {
new {Name="Fake 1",City="NY"},
new {Name="Fake 2",City="London"}};

using (RecordExpectations r = new RecordExpectations())
{
// don't hit the database, instead return test customers
         Northwind db = new Northwind(connStr) ;
var answer = from c in db.Customers
where c.City == "not-used"
select new { c.Name, c.City };
r.Return(fake);
}
CallClassUnderTest();
// Continue with test
}

Comments about this syntax are welcome

Dependency Injection – Keep your privates to yourself

Eli Lopian    .NET Tests, TDD    

Jacob Proffitt has hit the nail on the head with his “I do wish that people would admit that DI doesn’t have compelling applicability outside of Unit Testing” post, the discussion continues with Nate Kohari response post and Jacobs counter post. Oren has also joined in with two posts.

Here a some ideas for you to think about.

DI as a Silver Bullet – You lose power

When you use DI as a ’Silver Bullet’ you are losing more then half the abilities of your programming language. You can not use static methods or the ‘new‘ keyword or sealed types. Oh, you have to make all your methods virtual too. This is going to be even harder once Extension Methods (and Linq) become main stream.

Code to Enable Change – Costs More

Creating Code that is there only to “Enable Change” has a big “YAGNI” written all over it. (Making the code more complex and thus wasting time in development and then in maintenance, for a chance that it will be used in the future). We have understood that this is the wrong plan ages ago. We now know that we can not predict the future and it is best to change our code only when we need to (a process called refactoring).

Keep your Privates to Yourself

Jacob, you are quite right about DI coming into fashion only because the tools where not good enough. DI does have other applications outside testing, but it is being overused in most application only to make the code testable.

One of the first issues that was discussed when TDD was starting was: “should we change our code to make it testable?”
Should we change the visibility of our code?
Should we change the design of our code?
This lead to a collision between testable code and OO encapsulation. Developers started to expose private parts of the code to enable testing. It started with private fields and methods and now it is the complete design. This collision still exists when using inadequate tools, but with the right tools, you can enjoy the best of both worlds.

Get the Best Tools to get the Job Done

Thousands of developers have understood this and have started testing there code without being forced to use a specific pattern required by some tools. Many development shops, didn’t test their code because of the testability/design collision. With the right tools they now understand and test their code.

As Joel Says: “Get the best tools“

A New Trick

Eli Lopian    .NET Tests, TDD    

I have read this post Interaction based testing using TypeMock.

This code:

Mock clientMock = MockManager.Mock(typeof (Client));
clientMock.Strict = true;

Client client = new Client();

Is exactly the same as this code:

MockObject<Client> clientMock = MockManager.MockObject<Client>();

Client client = clientMock.Object;

I prefer the latter, the main reason being that using MockObject  ensures that the Object is the one being mocked.

Here is an example that won’t work because we added a new Mock before the previous code:

Mock firstClientMock = MockManager.Mock(typeof (Client));

Mock clientMock = MockManager.Mock(typeof (Client));
clientMock.Strict = true;

Client client = new Client();  // this will be contolled by firstClientMock 

In this case our client is controlled by the firstClientMock instead of the clientMock. This won’t happen if we use MockObject