I need help testing the following code
public virtual void Update(T entity)
{
if (entity == null)
{
throw new ArgumentNullException("entity");
}
int iretries = 0;
bool success = false;
do
{
try
{
this.context.SaveChanges();
success = true;
}
catch (DbUpdateConcurrencyException ex)
{
// Get the current entity values and the values in the database
// as instances of the entity type
var entry = ex.Entries.Single();
var databaseValues = entry.GetDatabaseValues();
// Choose an initial set of resolved values. In this case we
// make the default be the values currently in the database: StoreWins
object resolvedValues = ResolveConcurrency(databaseValues.ToObject());
// Update the original values with the database values and
// the current values with whatever the user choose.
entry.OriginalValues.SetValues(databaseValues);
entry.CurrentValues.SetValues(resolvedValues);
// give up after n retries
if (++iretries == NUMBER_OF_CONC_RETRIES)
throw;
}
catch (Exception)
{
//rethrow
throw;
}
} while (!success);
}
I want to unit test the DbUpdateConcurrencyException branch.
So, one simple test scenario would be:
- Creating a new
DbUpdateConcurrencyException - Mock the
SaveChangesto throw the above exception - Verify that
SaveChangeswas called a number ofNUMBER_OF_CONC_RETRIES - Assert that the
Updatemethod re-throws the exception
In the current state, the above test scenario cannot be tested, I cannot mock the exception to contain a IEnumerable<DbEntityEntry> with a single DbEntityEntry; I cannot mock the GetDatabaseValues(), etc.
A simple solution would be to insert a new layer of abstraction; let’s say using an interface to abstract the entire code that currently sits in the catch block, and to provide a mock that does nothing.
But then I would end up in the situation when I would want to test the implementation of that interface, and would end up having the same questions as above. How can I mock the DbUpdateConcurrencyException, the GetDatabaseValues, etc.
I am using moq for mocking.
Thank you for your input
If you cannot mock something you must hide it behind something else you can mock or override in test. Your test actually doesn’t need to use all that stuff for loading values and setting them in the entry – that is all dependent on EF and you will not test it when mocking the context because that would mean to re-implement EF’s logic behind
SaveChanges. All you need to do is:Where
RefreshValuescan beprotected virtualmethod and you can override it in your test either by providing test version of the class (you can even achieve this with Moq) or by inheriting the test from this class and overriding the method directly in test class.To setup Moq you need interface for your context exposing SaveChanges method:
If you need to test that it works for few throws as well you need to keep counter in the test and use it in the callback to decide if throw or not.