My Adventures in Coding

February 24, 2014

C# – Mocking a method to return a different value when called a second time using Moq

Filed under: .NET,c#,Mocking,Testing — Brian @ 2:36 pm
Tags: , , , ,

I have been using Moq as my primary mocking framework in C# for several years now. Overall I really like it, the syntax is easy to read, the mock setup is straight forward, etc. However, there are a few cases I need to mock infrequently and I always forget how to do the setup. Often because I am cycling between Scala, Python, and C#. So in this post I am just listing those three cases in hopes they may help others, yet at the same time as a reference to myself!

So for this example, first here is my example service that we will be mocking in our tests:

namespace MoqExample
{
    public interface ISomeService
    {
        SomeStuff GetNextStuff();
        void DoStuff();
    }

    public class SomeService : ISomeService
    {
        public SomeStuff GetNextStuff()
        {
            return new SomeStuff();
        }

        public void DoStuff()
        {
        }
    }

    public class SomeStuff
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }
}

Return a different value the second time a mocked method is called

Let’s say I have a call in a service that returns the next item to process, such as pulling in customer requests from a queue that need to be processed in order, one at a time. In this case I might want to have a test that demonstrates the application can handle two different requests back to back, or even handle the case where there is an item to process, but the next item returned is empty, meaning there is nothing left to process. If I need to test this case there are several simple ways to do this with Moq.

The more well known approach is to just use a Queue and have the mock call Dequeue and return the result each time the mocked method is called.

[Test]
public void MogMethodThatReturnsADifferentValueWhenCalledASecondTimeUsingAQueue()
{
    Mock<ISomeService> _mockSomeService = new Mock<ISomeService>();
    var queueStuff = new Queue<SomeStuff>();
    queueStuff.Enqueue(new SomeStuff { Id = 1, Name = "Real" });
    queueStuff.Enqueue(null);
    _mockSomeService.Setup(x => x.GetNextStuff()).Returns(queueStuff.Dequeue);

    Assert.IsNotNull(_mockSomeService.Object.GetNextStuff());
    Assert.IsNull(_mockSomeService.Object.GetNextStuff());
}

The alternative is to use a feature in Moq called Sequences which allows you to set multiple return values, that will be returned one at a time in order, each time the mocked method is called.

[Test]
public void MogMethodThatReturnsADifferentValueWhenCalledASecondTimeUsingSequences()
{
    Mock<ISomeService> _mockSomeService = new Mock<ISomeService>();
    _mockSomeService.SetupSequence(x => x.GetNextStuff())
		    .Returns(new SomeStuff {Id = 1, Name = "Real"})
		    .Returns(null);

    Assert.IsNotNull(_mockSomeService.Object.GetNextStuff());
    Assert.IsNull(_mockSomeService.Object.GetNextStuff());
}

Throw an exception the first time a mocked method is called, return a value the second time

In this case I want to test that my application will handle the case that when a call to a service throws an exception, it will retry and if it receives a valid response on the second try, process the request successfully and continue. You can accomplish this by using a feature in Moq called “Callback”.

[Test]
public void MogMethodThatThrowsAnExceptionFirstTimeCalledAndAnObjectWithSecondTime()
{
    Mock<ISomeService> _mockSomeService = new Mock<ISomeService>();
    var calls = 0;
    _mockSomeService.Setup(x => x.GetNextStuff())
	.Returns(() => new SomeStuff {Id = 1, Name = "Real"})
	.Callback(() =>
	{
	    calls++;
	    if (calls == 1)
		throw new Exception("Failure");
	});

    Assert.Throws<Exception>(() => _mockSomeService.Object.GetNextStuff());
    Assert.IsNotNull(_mockSomeService.Object.GetNextStuff());
}

Now, it is true that you can use a Moq Sequence to return a different value each time a mocked method is called, but as far as I can tell you can only use this where the valid value is first and throwing an exception is the last item in the sequence. In my case above I explicitly wanted to test that an exception was thrown on the first call and a valid value was returned on the second call. However, if all you need to test in your code is how it handles a valid value on the first call and an exception being thrown on the second call, you can use a Sequence for your mock setup.

[Test]
public void MockMethodThatReturnsAnObjectFirstTimeCalledAndThrowsAnExceptionSecondTimeUsingSequences()
{
    Mock<ISomeService> _mockSomeService = new Mock<ISomeService>();
    _mockSomeService.SetupSequence(x => x.GetNextStuff())
	.Returns(new SomeStuff())
	.Throws<Exception>();

    Assert.IsNotNull(_mockSomeService.Object.GetNextStuff());
    Assert.Throws<Exception>(() => _mockSomeService.Object.GetNextStuff());  
}

Mock a void method to throw an exception

Lets say I have some void method that normally just silently does some task for me and has no need to have a return type, such as a call to write a stat or a log entry. However, if I want to test how my application handles the case when this call throws an exception, I can use the following setup to mock this method.

[Test]
public void MogMethodThatThrowsAnExceptionIsVoidAssertExceptionIsThrown()
{
    Mock<ISomeService> _mockSomeService = new Mock<ISomeService>();
    _mockSomeService.Setup(x => x.DoStuff()).Throws(new Exception("Failure"));

    Assert.Throws<Exception>(() => _mockSomeService.Object.DoStuff());
}

January 21, 2013

LINQ to SQL – Unit Testing a Repository

Filed under: .NET,c#,LINQ,Testing — Brian @ 10:47 pm
Tags: , ,

Over the last few months I have been using LINQ to SQL for accessing a SQL Server database from an MVC 4 WEB API application. Overall it works very well, and when looking at the SQL it generates, it does generate very efficient SQL. Also, I really like the LINQ to SQL syntax as well, very simple and clean, and it is easy to translate a SQL query into the LINQ to SQL syntax.

So normally in the past when I was testing a repository in Java/Scala projects that used Hibernate, we just used SQLite for our unit tests. But since the syntax used in LINQ to SQL is just LINQ expressions, I was wondering if it would be possible to unit test the LINQ expressions in my repository by just passing in a list of objects.

I looked at several existing solutions for unit testing repositories using LINQ to SQL, which looked good, but they each had the same problem. They were creating a repository with a DataContext being provided in the constructor, which allowed it to be mocked in a test. But, the problem with this approach is that the DataContext is designed to be used for a single database transaction, so you should always create and dispose of a new DataContext for reach request to the database. For Example I would expect each method in the repository to look like:

using (var db = new EmployeeDataContext(new DataContext(_connectionString)))
{
    return (from employee in db.Employees() where employee.Id == id select employee).SingleOrDefault();
} 

Instead of:

return (from employee in existingContext.Employees() where employee.Id == id select employee).SingleOrDefault();

The only way this other approach would work reliably would be if the application were creating a new instance of the repository class on every request, but I did not want to do that. So the solution I came up with to get the tests working the way I wanted AND while still creating a new DataContext for each transaction, was to create a wrapper class for the DataContext. This allowed me create a stub for the DataContextWrapper that could be used to replace the real one in a test. This may not be the most eloquent solution, but it worked for what I needed. If anyone has a cleaner solution for accomplishing this, please let me know!

Let’s use the standard database “Employee” example, just to be consistent.

Note: I used Moqand NUnit in this example.

Employee Entity
Just a standard LINQ to SQL entity object

[Table(Name = "dbo.Employee")]
public class EmployeeEntity
{
    [Column(IsPrimaryKey = true, IsDbGenerated = true)] public int Id { get; set; }
    [Column] public string FirstName { get; set; }
    [Column] public string LastName { get; set; }
    [Column] public DateTime StartDate { get; set; }
    public override string ToString()
    {
        return string.Format("Id={0}, FirstName={1}, LastName={2}, StartDate={3}", Id, FirstName, LastName, StartDate);
    }
}

Employee Data Context
DataContext for accessing the “Employees” table in our database.

public interface IEmployeeDataContext : IDisposable
{
    ITable<EmployeeEntity> Employees();
    void ExecuteCommand(string command, params object[] parameters);
    void SubmitChanges();
}

public class EmployeeDataContext : IEmployeeDataContext
{
    private readonly DataContext _dataContext;

    public EmployeeDataContext(DataContext dataContext)
    {
        _dataContext = dataContext;
    }

    public ITable<EmployeeEntity> Employees()
    {
        return _dataContext.GetTable<EmployeeEntity>();
    }

    public void ExecuteCommand(string command, params object[] parameters)
    {
        _dataContext.ExecuteCommand(command, parameters);
    }

    public void SubmitChanges()
    {
        _dataContext.SubmitChanges();
    }

    public void Dispose()
    {
        _dataContext.Dispose();
    }
}

Data Context Wrapper
Now, let’s wrap the EmployeeDataContext in another class that has a method called CreateDataContext() which allows us to create a new EmployeeDataContext.

public interface IDataContextWrapper
{
    IEmployeeDataContext CreateDataContext();
}

public class DataContextWrapper: IDataContextWrapper
{
    private readonly string _connectionString;
    public DataContextWrapper(string connectionString)
    {
        _connectionString = connectionString;
    }

    public IEmployeeDataContext CreateDataContext()
    {
        return new EmployeeDataContext(new DataContext(_connectionString));
    }
}

Employee Repository
The constructor of our EmployeeRepository now takes a parameter of type IDataContextWrapper. So in each method that calls the database, it can now call _dataContextWrapper.CreateDataContext() in a using block to create a new DataContext for the request and also ensure the DataContext will be disposed.

public interface IEmployeeRepository
{
    EmployeeEntity AddEmployee(EmployeeEntity employee);
    EmployeeEntity GetEmployee(int id);
    List<EmployeeEntity> GetAllEmployees();
    List<EmployeeEntity> GetEmployeesByLastName(string lastName);
    List<EmployeeEntity> GetEmployeesByStartDate(DateTime minDate, DateTime maxDate);
}

public class EmployeeRepository : IEmployeeRepository
{
    private readonly IDataContextWrapper _dataContextWrapper;

    public EmployeeRepository(IDataContextWrapper dataContextWrapper)
    {
        _dataContextWrapper = dataContextWrapper;
    }

    public EmployeeEntity AddEmployee(EmployeeEntity employee)
    {       
        using (var db = _dataContextWrapper.CreateDataContext())
        {
            db.Employees().InsertOnSubmit(employee);
            db.SubmitChanges();
            return employee;
        }    
    }

    public EmployeeEntity GetEmployee(int id)
    {
        using (var db = _dataContextWrapper.CreateDataContext())
        {
            return (from employee in db.Employees() where employee.Id == id select employee).SingleOrDefault();
        }        
    }

    public List<EmployeeEntity> GetAllEmployees()
    {
        using (var db = _dataContextWrapper.CreateDataContext())
        {
            return (from employee in db.Employees() select employee).ToList();
        }  
    }

    public List<EmployeeEntity> GetEmployeesByLastName(string lastName)
    { 
        using (var db = _dataContextWrapper.CreateDataContext())
        {
            return (from employee in db.Employees() where employee.LastName == lastName select employee).ToList();
        }    
    }

    public List<EmployeeEntity> GetEmployeesByStartDate(DateTime minDate, DateTime maxDate)
    {
        using (var db = _dataContextWrapper.CreateDataContext())
        {
            return (from employee in db.Employees() where employee.StartDate >= minDate && employee.StartDate <= maxDate select employee).ToList();
        }
    }
}

Stub Data Context Wrapper
Now let’s create a stub class for our DataContextWrapper which will be used to replace the real one in our unit tests.

public class StubDataContextWrapper : IDataContextWrapper
{
    private readonly IEmployeeDataContext _dataContext;
    public StubDataContextWrapper(IEmployeeDataContext dataContext)
    {
        _dataContext = dataContext;
    }

    public IEmployeeDataContext CreateDataContext()
    {
        return _dataContext;
    }
}

Stub Employee Table
Also, we will need to create a stub of the employee table, which will be used in our tests to wrap the list of EmployeeEntity objects we will return as the result from our EmployeeDataContext when it is mocked in our tests.

public class StubEmployeeTable : ITable<EmployeeEntity>
{
    protected List<EmployeeEntity> internalList;

    public StubEmployeeTable(List<EmployeeEntity> list)
    {
        internalList = list;
    }

    public void Attach(EmployeeEntity entity)
    {
    }

    public void DeleteOnSubmit(EmployeeEntity entity)
    {
        internalList.Remove(entity);
    }

    public void InsertOnSubmit(EmployeeEntity entity)
    {
        internalList.Add(entity);
    }

    public IEnumerator<EmployeeEntity> GetEnumerator()
    {
        return this.internalList.GetEnumerator();
    }

    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
    {
        return this.internalList.GetEnumerator();
    }

    public Type ElementType
    {
        get { return this.internalList.AsQueryable().ElementType; }
    }

    public System.Linq.Expressions.Expression Expression
    {
        get { return this.internalList.AsQueryable().Expression; }
    }

    public IQueryProvider Provider
    {
        get { return this.internalList.AsQueryable().Provider; }
    }
}

Employee Repository Unit Tests
Now we can write our unit tests around the EmployeeRepository. The first step is to mock the EmployeeDataContext. Next we create a StubDataContextWrapper passing in the mock object. Then to create the EmployeeRepository we pass in the StubDataContextWrapper. We setup some EmployeeEntity objects with data we will use for testing, then finally we set the test data as the return value for the Employees() method on the mock of our EmployeeDataContext, using the StubEmployeeTable to wrap the result, to make it look like a response from a LINQ to SQL query.

[TestFixture]
public class EmployeeRepositoryTest
{
    private Mock<IEmployeeDataContext> _mockEmployeeDataContext;
    private IDataContextWrapper _stubDataContextWrapper;
    private IEmployeeRepository _employeeRepository;

    [SetUp]
    public void Setup()
    {
        _mockEmployeeDataContext = new Mock<IEmployeeDataContext>();
        _stubDataContextWrapper = new StubDataContextWrapper(_mockEmployeeDataContext.Object);
        _employeeRepository = new EmployeeRepository(_stubDataContextWrapper);

        var employee1 = new EmployeeEntity { Id  = 1, FirstName = "John", LastName = "Smith", StartDate = new DateTime(2013,01,10)};
        var employee2 = new EmployeeEntity { Id  = 2, FirstName = "Frank", LastName = "Smith", StartDate = new DateTime(2013,01,15)};
        var employee3 = new EmployeeEntity { Id  = 3, FirstName = "Stan", LastName = "Johnson", StartDate = new DateTime(2013,01,20)};

        var employees = new List<EmployeeEntity> {employee1, employee2, employee3};
        _mockEmployeeDataContext.Setup(x => x.Employees()).Returns(new StubEmployeeTable(employees));
    }

    [Test]
    public void AddEmployeeShouldAddNewEmployeeWhenDoesNotExist()
    {
        _employeeRepository.AddEmployee(new EmployeeEntity { FirstName = "New", LastName = "Employee", StartDate = new DateTime(2013, 01, 25) });
        Assert.AreEqual(4, _employeeRepository.GetAllEmployees().Count);
    }

    [Test]
    public void GetAllEmployeesByIdShouldReturnEmployeeWhenIdExists()
    {
        var results = _employeeRepository.GetAllEmployees();
        Assert.AreEqual(3, results.Count);
    }

    [Test]
    public void GetEmployeeByIdShouldReturnEmployeeWhenIdExists()
    {
        var result = _employeeRepository.GetEmployee(1);
        Assert.AreEqual(1, result.Id);
    }

    [Test]
    public void GetEmployeesByLastNameShouldReturnEmployeeWhenLastNameMatches()
    {
        var results = _employeeRepository.GetEmployeesByLastName("Smith");
        Assert.AreEqual(2, results.Count);
    }

    [Test]
    public void GetEmployeesByStartDateShouldReturnEmployeeWhenStartDateIsWithinRange()
    {
        var results = _employeeRepository.GetEmployeesByStartDate(new DateTime(2013, 01, 14), new DateTime(2013, 01, 16));
        Assert.AreEqual(1, results.Count);
        Assert.AreEqual(new DateTime(2013, 01, 15), results[0].StartDate);
    }
}

That is all. Of course this example can be made more generic, but it is just a simple example. If you have an example that works better for LINQ to SQL, please let me know, I would be happy to hear about it!

February 26, 2011

Python – Getting Started with Python Mock

Filed under: Python,Testing — Brian @ 12:00 am
Tags: , , ,

These examples all use the Python Mock library. This post is just a quick “Getting Started” for someone who is new to using the Python Mock library, once you get started refer to the Python Mock Documentation.

First you will need to install the mock library:

pip install -U mock

Your test file will need the following import statement:

from mock import patch, Mock

To mock a method in a class to return a specific value use @patch.object.

@patch.object(my_module.MyClass, 'my_method')
def test_my_method_shouldReturnTrue_whenMyMethodReturnsSomeValue(self, mock_my_method):
    mock_my_method.return_value=True
    some_other_class =  SomeOtherClassThatUsesMyClass()
    result = some_other_class.method_under_test()
    self.assertTrue(result)

To mock a method in a class with @patch.object but return a different value each time it is called, use side_effect. Side effect allows you to define a custom method and have that method called each time your mock method is called. The value returned from this method will be used as the return value your mock method.

@patch.object(my_module.MyClass, 'my_method')
def test_my_method_shouldReturnMultipleValues_whenMyMethodReturnsSomeValue(self, mock_my_method):
    list_of_return_values= [True,False,False]
    def side_effect():
        return list_of_return_values.pop()
    mock_my_method.side_effect = side_effect
    some_other_class =  SomeOtherClassThatUsesMyClass()
    self.assertFalse(some_other_class.method_under_test())
    self.assertFalse(some_other_class.method_under_test())
    self.assertTrue(some_other_class.method_under_test())

To mock an entire class to test interactions with that class use @patch.

@patch('my_module.MyClass')
def test_my_method_shouldCallMyClassMethodMyMethod_whenSomeOtherClassMethodIsCalled(self, mock_my_class):
    some_other_class =  SomeOtherClassThatUsesMyClass()
    some_other_class.method_under_test()
    self.assertTrue(mock_my_class.called)

To mock an entire class with @patch and still set the return value of a method in that class, grab the instance of the mock object’s return value and set the method’s return value on the instance. There is a section on the patch page explaining how to do this.

@patch('my_module.MyClass')
def test_my_method_shouldReturnTrue_whenSomeOtherClassMethodIsCalledAndAReturnValueIsSet(self, mock_my_class):
    mc = mock_my_class.return_value
    mc.my_method.return_value = True
    some_other_class =  SomeOtherClassThatUsesMyClass()
    result = some_other_class.method_under_test()
    self.assertTrue(result)

Finally, here is the simple code I used as my “code under test” to write these example tests:

class MyClass():
    def my_method(self):
        pass

class SomeOtherClassThatUsesMyClass():
    def method_under_test(self):
        myclass = MyClass()
        return myclass.my_method()

There are many other features in the Python Mock library, but these are the basics that will help you get started!

March 5, 2008

TDD

Filed under: SD West 2008,Testing — Brian @ 8:12 pm
Tags:

During the talk on TDD (Test Driven Development) the loop of the TDD cycle was discussed. I realize some of you who have already read about this topic and are familiar with this cycle, but I just thought I would mention it.

The TDD Loop

  1. Write a small test for new functionality
  2. Write just enough code for the new functionality to pass the test
  3. Confirm that the revised system passes all tests
  4. Refactor to remove “code smells”
  5. Confirm that the revised system still passes all tests

So the question came up during the talk “How do you know how many tests to write?”. The answer to this question was “Write as many tests as you feel are necessary to feel confident that the code functions as it is supposed to”. Developers are very good at writing positive tests (tests that show the code does what it is supposed to), however developers need to learn to get into the mindset of writing negative tests (tests that exercise conditions that should not happen but might).

TDD is extremely useful and important. Part of the problem pointed out with adoption is that if developers are just told to write unit tests and use TDD but are never given a good explanation of “Why” it can cause resistance to moving in this direction.

Unit Testing Private Methods?

Filed under: Testing — Brian @ 8:05 pm
Tags: ,

There was a section of a lecture I attended by Robert C. Martin devoted to unit testing and the topic of writing unit tests for private methods was mentioned. So the question was “Should you write unit tests for private methods” and the answer was NO.

A class has an interface of public methods. Those public methods use private methods. You write test cases for the public methods to ensure all functionality the class provides is covered by tests. If you need to write unit tests specifically for the private methods, then your test cases for the public methods are probably not covering all cases, and if they do, then the tests for the private methods are just duplicates of the public method test cases. One of the main problems with unit tests on private methods is that they make it difficult to refactor the inner workings of a class.

A developer should have the freedom to refactor the code within a class without needing to re-write existing unit tests. We should be working at removing obstacles to refactoring and creating meaningful interfaces to our code that are both straight forward for development and testing. If you absolutely feel a private method in a class is complicated enough that it warrants being unit tested on it’s own, then perhaps that is functionality that should be broken out into it’s own class.

The public methods of a class are an interface. One job of unit tests is to explain the correct usage of a class to the next developer who uses it. Trying to unit test the private methods of a class will just make it more difficult for other developers to understand.

Unit Testing

Filed under: SD West 2008,Testing — Brian @ 7:56 pm

Part of the afternoon talk was on unit testing. There was a lot of material covered, so here are just a few topics discussed.

  • Always remember that when you are adding unit tests you are adding more code that will now need to be maintained. Writing difficult to understand or brittle unit tests will cause future maintenance problems.
  • Unit tests must be highly readable so that they will be easier for developers to understand in the future as they are also a form of documentation. Reading existing unit tests are also a great way for a developer to quickly understand how an existing class is supposed to be used.
  • Never have a conditional or loop in a unit test, if you do, you must rewrite the test.
  • Unit tests should always be simple.
  • Unit tests are extremely important. TDD is important, but if there is an area of an application that is not currently covered by unit tests there is still a great deal of value in adding unit tests to these areas of the application

Create a free website or blog at WordPress.com.