I am using asp net core 1.0 and xunit.
I am trying to write a unit test for some code that uses IMemoryCache. However whenever I try to set a value in the IMemoryCache I get an Null reference error.
My unit test code is like this:
The IMemoryCache is injected into the class I want to test. However when I try to set a value in the cache in the test I get a null reference.
public Test GetSystemUnderTest()
{
var mockCache = new Mock<IMemoryCache>();
return new Test(mockCache.Object);
}
[Fact]
public void TestCache()
{
var sut = GetSystemUnderTest();
sut.SetCache("key", "value"); //NULL Reference thrown here
}
And this is the class Test...
public class Test
{
private readonly IMemoryCache _memoryCache;
public Test(IMemoryCache memoryCache)
{
_memoryCache = memoryCache;
}
public void SetCache(string key, string value)
{
_memoryCache.Set(key, value, new MemoryCacheEntryOptions {SlidingExpiration = TimeSpan.FromHours(1)});
}
}
My question is...Do I need to setup the IMemoryCache somehow? Set a value for the DefaultValue? When IMemoryCache is Mocked what is the default value?
IMemoryCache.Set Is an extension method and thus cannot be mocked using Moq framework.
The code for the extension though is available here
public static TItem Set<TItem>(this IMemoryCache cache, object key, TItem value, MemoryCacheEntryOptions options)
{
using (var entry = cache.CreateEntry(key))
{
if (options != null)
{
entry.SetOptions(options);
}
entry.Value = value;
}
return value;
}
For the test, a safe path would need to be mocked through the extension method to allow it to flow to completion. Within Set it also calls extension methods on the cache entry, so that will also have to be catered for. This can get complicated very quickly so I would suggest using a concrete implementation
//...
using Microsoft.Extensions.Caching.Memory;
using Microsoft.Extensions.DependencyInjection;
//...
public Test GetSystemUnderTest() {
var services = new ServiceCollection();
services.AddMemoryCache();
var serviceProvider = services.BuildServiceProvider();
var memoryCache = serviceProvider.GetService<IMemoryCache>();
return new Test(memoryCache);
}
[Fact]
public void TestCache() {
//Arrange
var sut = GetSystemUnderTest();
//Act
sut.SetCache("key", "value");
//Assert
//...
}
So now you have access to a fully functional memory cache.
TLDR
Scroll down to the code snippet to mock the cache setter indirectly (with a different expiry property)
/TLDR
While it's true that extension methods can't be mocked directly using Moq or most other mocking frameworks, often they can be mocked indirectly - and this is certainly the case for those built around IMemoryCache
As I have pointed out in this answer, fundamentally, all of the extension methods call one of the three interface methods somewhere in their execution.
Nkosi's answer raises very valid points: it can get complicated very quickly and you can use a concrete implementation to test things. This is a perfectly valid approach to use. However, strictly speaking, if you go down this path, your tests will depend on the implementation of third party code. In theory, it's possible that changes to this will break your test(s) - in this situation, this is highly unlikely to happen because the caching repository has been archived.
Furthermore there is the possibility that using a concrete implementation with a bunch of dependencies might involve a lot of overheads. If you're creating a clean set of dependencies each time and you have many tests this could add quite a load to your build server (I'm not saying that that's the case here, it would depend on a number of factors)
Finally you lose one other benefit: by investigating the source code yourself in order to mock the right things, you're more likely to learn about how the library you're using works. Consequently, you might learn how to use it better and you will almost certainly learn other things.
For the extension method you are calling, you should only need three setup calls with callbacks to assert on the invocation arguments. This might not be appropriate for you, depending on what you're trying to test.
[Fact]
public void TestMethod()
{
var expectedKey = "expectedKey";
var expectedValue = "expectedValue";
var expectedMilliseconds = 100;
var mockCache = new Mock<IMemoryCache>();
var mockCacheEntry = new Mock<ICacheEntry>();
string? keyPayload = null;
mockCache
.Setup(mc => mc.CreateEntry(It.IsAny<object>()))
.Callback((object k) => keyPayload = (string)k)
.Returns(mockCacheEntry.Object); // this should address your null reference exception
object? valuePayload = null;
mockCacheEntry
.SetupSet(mce => mce.Value = It.IsAny<object>())
.Callback<object>(v => valuePayload = v);
TimeSpan? expirationPayload = null;
mockCacheEntry
.SetupSet(mce => mce.AbsoluteExpirationRelativeToNow = It.IsAny<TimeSpan?>())
.Callback<TimeSpan?>(dto => expirationPayload = dto);
// Act
var success = _target.SetCacheValue(expectedKey, expectedValue,
new MemoryCacheEntryOptions().SetAbsoluteExpiration(TimeSpan.FromMilliseconds(expectedMilliseconds)));
// Assert
Assert.True(success);
Assert.Equal("key", keyPayload);
Assert.Equal("expectedValue", valuePayload as string);
Assert.Equal(expirationPayload, TimeSpan.FromMilliseconds(expectedMilliseconds));
}
public sealed class NullMemoryCache : IMemoryCache
{
public ICacheEntry CreateEntry(object key)
{
return new NullCacheEntry() { Key = key };
}
public void Dispose()
{
}
public void Remove(object key)
{
}
public bool TryGetValue(object key, out object value)
{
value = null;
return false;
}
private sealed class NullCacheEntry : ICacheEntry
{
public DateTimeOffset? AbsoluteExpiration { get; set; }
public TimeSpan? AbsoluteExpirationRelativeToNow { get; set; }
public IList<IChangeToken> ExpirationTokens { get; set; }
public object Key { get; set; }
public IList<PostEvictionCallbackRegistration> PostEvictionCallbacks { get; set; }
public CacheItemPriority Priority { get; set; }
public long? Size { get; set; }
public TimeSpan? SlidingExpiration { get; set; }
public object Value { get; set; }
public void Dispose()
{
}
}
}
I had a similar issue but I want to disable caching for debugging occasionally as its a pain to keep having to clear the cache. Just mock/fake them yourself (using StructureMap dependency injection).
You could easily use them in you tests as well.
public class DefaultRegistry: Registry
{
public static IConfiguration Configuration = new ConfigurationBuilder()
.SetBasePath(HttpRuntime.AppDomainAppPath)
.AddJsonFile("appsettings.json")
.Build();
public DefaultRegistry()
{
For<IConfiguration>().Use(() => Configuration);
#if DEBUG && DISABLE_CACHE <-- compiler directives
For<IMemoryCache>().Use(
() => new MemoryCacheFake()
).Singleton();
#else
var memoryCacheOptions = new MemoryCacheOptions();
For<IMemoryCache>().Use(
() => new MemoryCache(Options.Create(memoryCacheOptions))
).Singleton();
#endif
For<SKiNDbContext>().Use(() => new SKiNDbContextFactory().CreateDbContext(Configuration));
Scan(scan =>
{
scan.TheCallingAssembly();
scan.WithDefaultConventions();
scan.LookForRegistries();
});
}
}
public class MemoryCacheFake : IMemoryCache
{
public ICacheEntry CreateEntry(object key)
{
return new CacheEntryFake { Key = key };
}
public void Dispose()
{
}
public void Remove(object key)
{
}
public bool TryGetValue(object key, out object value)
{
value = null;
return false;
}
}
public class CacheEntryFake : ICacheEntry
{
public object Key {get; set;}
public object Value { get; set; }
public DateTimeOffset? AbsoluteExpiration { get; set; }
public TimeSpan? AbsoluteExpirationRelativeToNow { get; set; }
public TimeSpan? SlidingExpiration { get; set; }
public IList<IChangeToken> ExpirationTokens { get; set; }
public IList<PostEvictionCallbackRegistration> PostEvictionCallbacks { get; set; }
public CacheItemPriority Priority { get; set; }
public long? Size { get; set; }
public void Dispose()
{
}
}
I also came across this problem in a .Net 5 project and I solved it by wrapping the memory cache and only exposing the functionality that I need. This way I conform to the ISP and it's easier to work with my unit tests.
I created an interface
public interface IMemoryCacheWrapper
{
bool TryGetValue<T>(string Key, out T cache);
void Set<T>(string key, T cache);
}
Implemented the memory cache logic in my wrapper class, using MS dependency injection, so I'm not reliant on those implementation details in my class under test, plus it has the added benefit of adhering to the SRP.
public class MemoryCacheWrapper : IMemoryCacheWrapper
{
private readonly IMemoryCache _memoryCache;
public MemoryCacheWrapper(IMemoryCache memoryCache)
{
_memoryCache = memoryCache;
}
public void Set<T>(string key, T cache)
{
_memoryCache.Set(key, cache);
}
public bool TryGetValue<T>(string Key, out T cache)
{
if (_memoryCache.TryGetValue(Key, out T cachedItem))
{
cache = cachedItem;
return true;
}
cache = default(T);
return false;
}
}
I added my memory cache wrapper to the dependency injection and I replaced the system memory cache in my code with the wrapper and that is what I mock out in my tests. All in all a relatively quick job and I think a better structure too.
In my test I then added this so that it mimics the cache updating.
_memoryCacheWrapperMock = new Mock<IMemoryCacheWrapper>();
_memoryCacheWrapperMock.Setup(s => s.Set(It.IsAny<string>(), It.IsAny<IEnumerable<IClientSettingsDto>>()))
.Callback<string, IEnumerable<IClientSettingsDto>>((key, cache) =>
{
_memoryCacheWrapperMock.Setup(s => s.TryGetValue(key, out cache))
.Returns(true);
});
This can be done by mocking the TryGetValue method for IMemoryCache instead of the Set method (Which as mentioned is an extension method and thus cannot be mocked).
var mockMemoryCache = Substitute.For<IMemoryCache>();
mockMemoryCache.TryGetValue(Arg.Is<string>(x => x.Equals(key)), out string expectedValue)
.Returns(x =>
{
x[1] = value;
return true;
});
var converter = new sut(mockMemoryCache);
Related
My C# classes are generally structured this way:
public class MyDummyService
{
private readonly MyConfigClass _config;
public MyDummyService(IOptions<MyConfigClass> options)
{
_config = options.Value;
}
public string DoSomethingWithTheNumber()
{
if (_config.SomeValue % 2 == 0)
return "foo";
return "bar";
}
}
public class MyConfigClass
{
public int SomeValue{get; set;}
public string SomeName {get; set;}
}
Clearly, IOptions<MyConfigClass> is used to map configurations from the appSettings.json file.
Then, I can test such classes like this:
class MyDummyServiceTests
{
protected AutoFixture.Fixture _fixture;
protected MyDummyService _sut;
protected MyConfigClass _simpleConfig;
protected Mock<IOptions<MyConfigClass>> _mockConfig;
public MyDummyServiceTests()
{
_fixture = new AutoFixture.Fixture();
_mockConfig = new Mock<IOptions<MyConfigClass>>();
_simpleConfig = _fixture.Build<MyConfigClass>()
.With(i => i.SomeValue, 4)
.With(i => i.SomeName, "Pippo")
.Create();
}
[SetUp]
public void Setup()
{
_mockConfig.SetupGet(m => m.Value).Returns(_simpleConfig);
_sut = new MyDummyService(_mockConfig.Object);
}
[TearDown]
public void TearDown()
{
_mockConfig.Reset();
}
public class DoSomethingWithTheNumber : MyDummyServiceTests
{
[Test]
public void Should_ReturnFoo_WhenNumberIsEven()
{
_simpleConfig = _fixture.Build<MyConfigClass>()
.With(_ => _.SomeValue, 10)
.Create();
var s = _sut.DoSomethingWithTheNumber();
Assert.AreEqual("foo", s);
}
[Test]
public void Should_ReturnBar_WhenNumberIsOdd()
{
_simpleConfig = _fixture.Build<MyConfigClass>()
.With(_ => _.SomeValue, 69)
.Create();
var s = _sut.DoSomethingWithTheNumber();
Assert.AreEqual("bar", s);
}
}
}
Yes, I know, I should use [TestCase] - you got the point
Now, when I set up tests for such classes, and I want to test a specific behavior that depends on the MyConfigClass.SomeValue value, I don't want to re-initialize everything. I can clearly just add _mockConfig.SetupGet(m => m.Value).Returns(_simpleConfig); or _sut = new MyDummyService( Options.Create(_simpleConfig)); but I want to keep my tests as small as possible, and only set the configuration value I need.
If I run the tests as such, DoSomethingWithTheNumber() does not see MyConfigClass.SomeValue with the correct value, because it is initialized and assigned to _config during StartUp phase, so before I set the correct value in my tests.
How can I improve my approach and set only the values necessary to have the specific test pass?
Note: I do not expect my configurations to change at runtime. Therefore, I can use IOptions<T>, IOptionsMonitor<T>, or IOptionsSnapshot<T> - even if they are different meanings, as explained here.
I am using a shared database fixture for my tests, but when running multiple tests at the same time, I get the following error message:
System.InvalidOperationException: A second operation was started on this context before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext. For more information on how to avoid threading issues with DbContext, see https://go.microsoft.com/fwlink/?linkid=2097913.
This is my code of my Fixture:
public class SharedDatabaseFixture : IDisposable
{
public static readonly object _lock = new object();
private static bool _databaseInitialized;
private const string postgresConnectionString = "Host=localhost;Database=IntegrationTests; Username=postgres;Password=password";
public SharedDatabaseFixture()
{
Connection = new NpgsqlConnection(postgresConnectionString);
Seed();
Connection.Open();
}
public DbConnection Connection { get; }
public AppDbContext CreateContext(DbTransaction transaction = null!)
{
var serviceProvider = new ServiceCollection()
.AddEntityFrameworkNpgsql()
.AddMediatR(typeof(IAggregateRoot).Assembly)
.AddScoped(typeof(IAsyncRepository<>), typeof(EfRepository<>))
.AddDbContext<AppDbContext>(options => options.UseNpgsql(Connection))
.BuildServiceProvider();
ServiceLocator.SetLocatorProvider(serviceProvider);
DomainEvents.Mediator = () => ServiceLocator.Current.GetInstance<IMediator>();
var builder = new DbContextOptionsBuilder<AppDbContext>();
builder.UseNpgsql(Connection).UseInternalServiceProvider(serviceProvider);
var context = new AppDbContext(builder.Options);
if (transaction != null)
{
context.Database.UseTransaction(transaction);
}
return context;
}
private void Seed()
{
lock (_lock)
{
if (!_databaseInitialized)
{
using (var context = CreateContext())
{
context.Database.EnsureDeleted();
context.Database.EnsureCreated();
var appDbContextSeed = new AppDbContextSeed(context);
appDbContextSeed.SeedAsync().Wait();
}
_databaseInitialized = true;
}
}
}
public void Dispose() => Connection.Dispose();
}
The code I am testing uses events and those events do queries to the database. Therefore, I am registering some services and also a DbContext.
The problem is, when I run multiple tests at the same time, events are raised at the same time as well and because they are all using the same DbContext, it throws an exception when two handlers try to use the DbContext at the same time.
So, my question is: how can I instantiate a DbContext for each test (but using the same connection) or prevent it from using the DbContext at the same time?
An Example of one of my tests:
public class Project_Create : IClassFixture<SharedDatabaseFixture>
{
public SharedDatabaseFixture Fixture { get; }
public Project_Create(SharedDatabaseFixture fixture) => Fixture = fixture;
[Fact]
public void Creates_succesfully()
{
var project = new Project(SeedConstants.TEST_COMPANY_ID, "ABC", "Hallo123", "2018-123");
Assert.Equal(SeedConstants.TEST_COMPANY_ID, project.CompanyId);
Assert.Equal("ABC", project.Code);
Assert.Equal("Hallo123", project.Description);
Assert.Equal("2018-123", project.Number);
}
}
Project.cs:
public class Project : BaseEntity<Guid, ProjectValidator, Project>, IAggregateRoot
{
public Guid CompanyId { get; private set; }
public string Code { get; private set; }
public string Description { get; private set; }
public string Number { get; private set; }
public Project(Guid companyId, string code, string description, string number)
{
CompanyId = companyId;
Code = code;
Description = description;
Number = number;
Validate(this);
DomainEvents.Raise(new SetCompanyIdEvent(companyId)).GetAwaiter().GetResult();
}
}
As you can see, this project class raises an event. This event has a handler and looks like this:
public class CheckIfProjectIdExistsHandler : INotificationHandler<SetProjectIdEvent>
{
private readonly IAsyncRepository<Project> _projectRepository;
public CheckIfProjectIdExistsHandler(IAsyncRepository<Project> projectRepository)
{
_projectRepository = projectRepository;
}
public async Task Handle(SetProjectIdEvent notification, CancellationToken cancellationToken)
{
var project = await _projectRepository.GetByIdAsync(notification.ProjectId, cancellationToken);
if (project == null)
{
throw new ProjectDoesNotExistsException($"The project with ID {notification.ProjectId} does not exist.");
}
}
}
I hope this illustrates what I am testing
The answer is always simpler than you think.
When adding the DbContext in the Service Provider, I didn't specify the ServiceLifetime, so it is a singleton by default. Changing this to Transient solves the issue. Then the Connection should also be changed by the connectionString, so there are no multiple operations on the same connection.
So, this line:
.AddDbContext<AppDbContext>(options => options.UseNpgsql(Connection))
Should be change like so:
.AddDbContext<AppDbContext>(options => options.UseNpgsql(postgresConnectionString), ServiceLifetime.Transient)
Also, The registration of the repository should be as Transient and not Scoped.
Is there in C# some kind of equivalent of ExpectedSystemExit in Java? I have an exit in my code and would really like to be able to test it. The only thing I found in C# is a not really nice workaround.
Example Code
public void CheckRights()
{
if(!service.UserHasRights())
{
Environment.Exit(1);
}
}
Test Code
[TestMethod]
public void TestCheckRightsWithoutRights()
{
MyService service = ...
service.UserHasRights().Returns(false);
???
}
I am using the VS framework for testing (+ NSubstitute for mocking) but it is not a problem to switch to nunit or whatever for this test.
You should use dependency injection to supply to the class being tested an interface that provides an environmental exit.
For example:
public interface IEnvironment
{
void Exit(int code);
}
Let's also assume that you have an interface for calling UserHasRights():
public interface IRightsService
{
bool UserHasRights();
}
Now suppose your class to be tested looks like this:
public sealed class RightsChecker
{
readonly IRightsService service;
readonly IEnvironment environment;
public RightsChecker(IRightsService service, IEnvironment environment)
{
this.service = service;
this.environment = environment;
}
public void CheckRights()
{
if (!service.UserHasRights())
{
environment.Exit(1);
}
}
}
Now you can use a mocking framework to check that IEnvironment .Exit() is called under the right conditions. For example, using Moq it might look a bit like this:
[TestMethod]
public static void CheckRights_exits_program_when_user_has_no_rights()
{
var rightsService = new Mock<IRightsService>();
rightsService.Setup(foo => foo.UserHasRights()).Returns(false);
var enviromnent = new Mock<IEnvironment>();
var rightsChecker = new RightsChecker(rightsService.Object, enviromnent.Object);
rightsChecker.CheckRights();
enviromnent.Verify(foo => foo.Exit(1));
}
Ambient contexts and cross-cutting concerns
A method such as Environment.Exit() could be considered to be a cross-cutting concern, and you might well want to avoid passing around an interface for it because you can end up with an explosion of additional constructor parameters. (Note: The canonical example of a cross cutting concern is DateTime.Now.)
To address this issue, you can introduce an "Ambient context" - a pattern which allows you to use a static method while still retaining the ability to unit test calls to it. Of course, such things should be used sparingly and only for true cross-cutting concerns.
For example, you could introduce an ambient context for Environment like so:
public abstract class EnvironmentControl
{
public static EnvironmentControl Current
{
get
{
return _current;
}
set
{
if (value == null)
throw new ArgumentNullException(nameof(value));
_current = value;
}
}
public abstract void Exit(int value);
public static void ResetToDefault()
{
_current = DefaultEnvironmentControl.Instance;
}
static EnvironmentControl _current = DefaultEnvironmentControl.Instance;
}
public class DefaultEnvironmentControl : EnvironmentControl
{
public override void Exit(int value)
{
Environment.Exit(value);
}
public static DefaultEnvironmentControl Instance => _instance.Value;
static readonly Lazy<DefaultEnvironmentControl> _instance = new Lazy<DefaultEnvironmentControl>(() => new DefaultEnvironmentControl());
}
Normal code just calls EnvironmentControl.Current.Exit(). With this change, the IEnvironment parameter disappears from the RightsChecker class:
public sealed class RightsChecker
{
readonly IRightsService service;
public RightsChecker(IRightsService service)
{
this.service = service;
}
public void CheckRights()
{
if (!service.UserHasRights())
{
EnvironmentControl.Current.Exit(1);
}
}
}
But we still retain the ability to unit-test that it has been called:
public static void CheckRights_exits_program_when_user_has_no_rights()
{
var rightsService = new Mock<IRightsService>();
rightsService.Setup(foo => foo.UserHasRights()).Returns(false);
var enviromnent = new Mock<EnvironmentControl>();
EnvironmentControl.Current = enviromnent.Object;
try
{
var rightsChecker = new RightsChecker(rightsService.Object);
rightsChecker.CheckRights();
enviromnent.Verify(foo => foo.Exit(1));
}
finally
{
EnvironmentControl.ResetToDefault();
}
}
For more information about ambient contexts, see here.
I ended up creating a new method which I can then mock in my tests.
Code
public void CheckRights()
{
if(!service.UserHasRights())
{
Environment.Exit(1);
}
}
internal virtual void Exit()
{
Environment.Exit(1);
}
Unit test
[TestMethod]
public void TestCheckRightsWithoutRights()
{
MyService service = ...
service.When(svc => svc.Exit()).DoNotCallBase();
...
service.CheckRights();
service.Received(1).Exit();
}
If your goal is to avoid extra classes/interfaces just to support tests, how do you feel about Environment.Exit action via Property Injection?
class RightsChecker
{
public Action AccessDeniedAction { get; set; }
public RightsChecker(...)
{
...
AccessDeniedAction = () => Environment.Exit();
}
}
[Test]
public TestCheckRightsWithoutRights()
{
...
bool wasAccessDeniedActionExecuted = false;
rightsChecker.AccessDeniedAction = () => { wasAccessDeniedActionExecuted = true; }
...
Assert.That(wasAccessDeniedActionExecuted , Is.True);
}
I'm looking to implement a caching tier in our application and accidentally came across ServiceStack's ICacheManager.
ICacheManager.Resolve looks as though it's exactly what I'm after (try and get, if it's not in the cache then call the function to get and store it). All documentation I can find however is about using ICacheClient.
How I can wire up ICacheManager using AutoFac? I assume I need to wire up a client e.g.:
_builder.Register(c => new MemoryCacheClient())
.As<ICacheClient>();
But then I'm not sure what ICacheManager should resolve to.
Is this a good idea or am I abusing ServiceStack?
I've added a custom cache manager for the time being but it feels wrong for some reason:
public class CacheManager : ICacheManager
{
public CacheManager(ICacheClient cacheClient)
{
CacheClient = cacheClient;
}
public void Clear(IEnumerable<string> cacheKeys)
{
Clear(cacheKeys.ToArray());
}
public void Clear(params string[] cacheKeys)
{
CacheClient.ClearCaches(cacheKeys.ToArray());
}
public ICacheClient CacheClient { get; private set; }
public T Resolve<T>(string cacheKey, Func<T> createCacheFn) where T : class
{
return Resolve(cacheKey, new TimeSpan(0, 15, 0), createCacheFn);
}
public T Resolve<T>(string cacheKey, TimeSpan expireIn, Func<T> createCacheFn) where T : class
{
var cacheResult = CacheClient.Get<T>(cacheKey);
if (cacheResult != null)
return cacheResult;
var item = createCacheFn();
CacheClient.Set(cacheKey, item, expireIn);
return item;
}
}
Here is my class:
public class AuditInfo
{
public String ActionDescription { get; set; }
public String ActionWho { get; set; }
public BasicProjectProfile Project { get; set; }
public AuditInfo ()
{ }
public void SaveInfo ()
{
using (CIHEntities _dbContext = new CIHEntities())
{
AuditInfoEntity aie = new AuditInfoEntity();
aie.ActionDescription = this.ActionDescription;
aie.ActionWhen = DateTime.Now;
if (this.ActionWho != null)
{
aie.ActionWho = this.ActionWho;
}
else
{
aie.ActionWho = "Not Specified";
}
aie.ProjectAssoc = _dbContext.ProjectEntity
.Where(r => r.Id == this.Project.Id)
.First();
_dbContext.SaveChanges();
}
}
}
CIHEntities is a Entity Framework Database.
I would like to unit test the SaveInfo method but it shouldn't actually save to the Database. How Can this be done?
Thanks
Eric
use the Repository pattern and move the responsibility for saving the enity to the Repository:
public class AuditInfo
{
public String ActionDescription { get; set; }
public String ActionWho { get; set; }
public BasicProjectProfile Project { get; set; }
}
write an interface for your repository:
public interface IRepository
{
void Save();
}
then your implemention:
public RealRepository : IRepository
{
public void SaveInfo ()
{
using (CIHEntities _dbContext = new CIHEntities())
{
AuditInfoEntity aie = new AuditInfoEntity();
aie.ActionDescription = this.ActionDescription;
aie.ActionWhen = DateTime.Now;
if (this.ActionWho != null)
{
aie.ActionWho = this.ActionWho;
}
else
{
aie.ActionWho = "Not Specified";
}
aie.ProjectAssoc = _dbContext.ProjectEntity
.Where(r => r.Id == this.Project.Id)
.First();
_dbContext.SaveChanges();
}
}
}
then make your client code that takes a repository as a parameter will be something like this
public class MyClient{
IRepository _repository;
public MyClient(){
_repository = new RealRepository();
}
public MyClient(IRepository repository)
{
_repository = repository;
}
public void Main(){
AuditInfo entity = new AuditInfo();
//do whatever you want
_repository.Save();
}
}
Your real application can use the default constructor which will use the RealRepository while you unit tests can can pass a Fake Repository implementation that doesn't talk to the database (or even better use a Mocking framework like Moq).
This is the basic concept, you can improve it to have a Generic Repository, use UoW pattern ... You can read more about it in this msdn article: Testability and EF
Given : that Id don't know what is the interface of CIHEntities
When : Unit Test is required for AuditInfo.SaveInfo
Then : inject the interface of CIHEntities from constructor of AuditInfo
Then : create a mock of CIHEntities from its interface and use it for Unit Test
Please mock the expectation and verify SaveChanges was called by using a mock library e.g Moq
Use the TransactionScope. Unless you actually commit the changes, it won't be added to the database. That's what I use in my unit tests, and it works flawlessly.
To use it, you have to add a reference to System.Transactions, and after that you might get some Windows error. If I remember correctly, you have to start some Windows Service.. However, Google it when you get that far.