I was thinking it would be nice to create a base class for NUnit test fixtures that opens a TransactionScope during the SetUp phase, then rolls back the transaction during tear down.
Something like this:
public abstract class TestFixtureBase
{
private TransactionScope _transaction;
[TestFixtureSetUp]
public void TestFixtureSetup()
{
_transaction = new TransactionScope();
}
[TestFixtureTearDown]
public void TestFixtureTearDown()
{
if (_transaction != null)
{
_transaction.Dispose();
}
}
}
Do you think this is a good idea?
Obviously the database is just a test database, not a live database, but it would still be annoying if it filled up with junk data from the unit tests.
What do other people do when running unit tests that involve a lot of data access?
You want to be careful here. TransactionScope is going to promote the transaction to a distributed transaction if you open up more than one connection to the database. I find that it is easier just to write some simple SQL that clears out the tables of interest to my test class before I start running the test.
EDIT: Normally I would call any test that touches the database an integration test since it involves another system. Typically, I will mock out the database when unit testing my code.
[TestSetup]
public void Setup()
{
foreach (string table in new string[] { "table1", "table2" })
{
ClearTable( table );
}
}
private void ClearTable( string table )
{
...standard stuff to set up connection...
SqlCommand command = connection.CreateCommand() );
command.CommandText = "delete from " + table;
command.ExecuteNonQuery();
... stuff to clean up connection...
}
I've used XtUnit
It automatically rolls back at the end of a unit test. You can simply add a [Rollback] attribute to the test. It's an extension to NUnit or MbUnit
Related
I'm currently working on WPF app that is architectured as follows:
MVVM
Entity Framwork 4 (with LINQ).
WCF service that pool Database to get data (Oracle).
I Make my WFC call in my View Model Class and put my data in an ObsevableCollections.
Db Changes occurs from a another app.
So my app does not do any write actions on the DB what-so-ever (Zéro), it only reads data and displays it on the UI.
How can I make my app to be quickly responsive to DB changes, I read about the following solutions but I'm confused and don't know what to use:
Pooling DB every n seconds with a DispatcherTimer (seems to be too much work cause data changes every millisecond)
SqlDependency, searched all over the internet but didn't find a proper implementation with EF.
As I said, db changes every millisecond (financial data from other sources),
How can resolve this?
Thank you.
i tried the code bellow and it seemed to be working okay for the moment (but i still have some doubts about that infinit loop), let me know what you thing :
public class MyViewModel
{
BackgroundWorker _bgWorker ;
//some props
//some funcs
protected internal MyViewModel(Session session)
{
Session = session;
RefreshData();
}
protected void RefreshData()
{
try
{
_bgWorker = new BackgroundWorker
{
WorkerReportsProgress = true,
WorkerSupportsCancellation = true
};
_bgWorker.DoWork += bgDoWork;
if (!_bgWorker.IsBusy)
{
_bgWorker.RunWorkerAsync();
}
}
catch (Exception)
{
_bgWorker.CancelAsync();
}
}
private void bgDoWork(object sender, DoWorkEventArgs e)
{
var worker = (BackgroundWorker)sender;
while (!worker.CancellationPending)
{
//Thread.Sleep(1000); should i keep this or not ?
Proxy(); // WCF calls
}
}
}
I have base class for my unit tests:
public abstract class DatabaseTestsBase
{
protected OvuContext DbContext;
protected TransactionScope TransactionScope;
[SetUp]
public void TestSetup()
{
TransactionScope = new TransactionScope(TransactionScopeOption.RequiresNew);
DbContext = new OvuContext("IntegrationTestContext");
}
[TearDown]
public void TestCleanup()
{
TransactionScope.Dispose();
}
}
And the test itself:
[TestFixture]
public class MyEntityTests : DatabaseTestsBase
{
[Test]
public void MyEntity_Create_HasSucceeded()
{
var myEntity = new MyEntity(Guid.NewGuid());
myEntity.Description = "bla bla bla";
var id = myEntity.Id;
DbContext.MyEntities.Add(myEntity);
DbContext.SaveChanges();
var temp = DbContext.MyEntities.Single(x => x.Id == id);
ComparisonResult result = CompareLogic.Compare(myEntity, temp);
Assert.True(result.AreEqual);
}
}
I got the following error when the test runs:
CREATE DATABASE statement not allowed within multi-statement transaction
The 'strange' thing is that when I run the test a second time, it passes.
I believe you are taking the pattern of rolling back database side-effecting Integration / Unit Tests done under an uncommitted transaction (such as TransactionScope) a bit far :)
Code First EF is attempting to create the database under the context of the ambient TransactionScope, which isn't possible.
In Sql Server (and possibly other RDBMS's), it isn't possible to execute certain statements, such as CREATE DATABASE, command under a transaction. You'll get the same error if you execute the following directly in SSMS:
use master;
BEGIN TRAN
CREATE DATABASE FOO;
-- CREATE DATABASE statement not allowed within multi-statement transaction.
I would suggest that you change your strategy such that you pre-create a permanent, empty test database for testing. Other DDL statements executed by EF Code First, such as CREATE TABLE can be rolled back by the uncommitted TransactionScope.
I have a database (SQL Server, Entity Framework) with 10-12 tables, around 5000 records. I want to code a unit test for a complex report that uses the data from those tables. What would be a good way to do that? I really do not want unit tests hitting an actual database...
Late to answer but its worth pointing out the NuGet package Effort allows you to fake an entire DbContext in memory from either a code-first or a database-first model.
I use it frequently & like it's ease of set up. You can use it to test issues that one could miss if trying to unit test with concrete fakes such as List<Entity>. (Issues caused by trying to load nav properties after the context is disposed for example)
A downside is that it does slow down the unit test a little1 which may be a concern for TDD or with a huge number of tests but I have always found it perfectly acceptable.
Simple use case outline for a db first set up would be as follows:
Add the nuget package for your EF version (package id: Effort.EF6 perhaps?)
Add an override to the constructor of your "MyEntities" class to enable Effort to pass in it's own connection string:
public partial class MyEntities
{
public MyEntities(DbConnection connection) : base(connection, true)
{
}
}
You can now create a 'Persistent' db store (persistent means it stays available after the context is disposed - it's not saved anywhere after the test run finishes!) with the following code:
var context = new MyEntities(Effort.EntityConnectionFactory.CreatePersistent("name=MyEntities"))
Just make sure you have the connection string to the db available in your app.config for the test project (used only to create the model)
Set up whatever mock data you need to test the context (I often have some simple data loaded using [ClassInitialize] or [TestInitialize] methods but it's easy to do whatever makes sense for your own set up):
[ClassInitialize]
public static void Initialise()
{
using (var context = new MyEntities(Effort.EntityConnectionFactory.CreatePersistent("name=MyEntities")))
{
context.Employees.Add(new Employee { Name = "John Doe", Skills = null});
context.Skills.Add(new Skill { Type = "C# Coding"});
context.SaveChanges();
}
}
Run your unit test using the in memory context:
[TestMethod]
public async Task CsSkillCanBeAssociatedWithEmployee()
{
//Arrange
using (var context = new MyEntities(Effort.EntityConnectionFactory.CreatePersistent("name=MyEntities")))
using (var sut = new SkillsMatrixService(context))
{
//Act
await sut.AddSkillToEmployeeAsync("Joe Bloggs","C# Coding");
}
//Assert
using (var context = new MyEntities(Effort.EntityConnectionFactory.CreatePersistent("name=MyEntities")))
{
var joesCSharpSkills = context
.Employees
.First(e => e.Name == "Joe Bloggs")
.Skills
.Where(s => s.Type == "C# Coding");
Assert.IsTrue(joesCSharpSkills.Any());
}
}
I'm given to understand you can load the initial set up for your db from csv config files to live in your project but I've always just set up dummy data in code as above.
1. Anecdotally, in my own (fairly limited) experience, 1 second or so is about usual to set it up and load some dummy data for a smallish model with around 20 entities and lots of nav properties - my machine isn't ultra fast. Naturally, your mileage may vary according to the complexity of your model and your hardware setup
I have a base object, that contains a Version property, marked as ConcurrencyCheck
public class EntityBase : IEntity, IConcurrencyEnabled
{
public int Id { get; set; }
[ConcurrencyCheck]
[Timestamp]
public byte[] Version { get; set; }
}
This works, however, I want to write a test to ensure it doesn't get broken. Unfortunately, I can't seem to figure out how to write a test that doesn't rely on the physical database!
And the relevant test code that works, but uses the database...
protected override void Arrange()
{
const string asUser = "ConcurrencyTest1"; // used to anchor and lookup this test record in the db
Context1 = new MyDbContext();
Context2 = new MyDbContext();
Repository1 = new Repository<FooBar>(Context1);
Repository2 = new Repository<FooBar>(Context2);
UnitOfWork1 = new UnitOfWork(Context1);
UnitOfWork2 = new UnitOfWork(Context2);
Sut = Repository1.Find(x => x.CreatedBy.Equals(asUser)).FirstOrDefault();
if (Sut == null)
{
Sut = new FooBar
{
Name = "Concurrency Test"
};
Repository1.Insert(Sut);
UnitOfWork1.SaveChanges(asUser);
}
ItemId = Sut.Id;
}
protected override void Act()
{
_action = () =>
{
var item1 = Repository1.FindById(ItemId);
var item2 = Repository2.FindById(ItemId);
item1.Name = string.Format("Changed # {0}", DateTime.Now);
UnitOfWork1.SaveChanges("test1");
item2.Name = string.Format("Conflicting Change # {0}", DateTime.Now);
UnitOfWork2.SaveChanges("test2"); //Should throw DbUpdateConcurrencyException
};
}
[TestMethod]
[ExpectedException(typeof(DbUpdateConcurrencyException))]
public void Assert()
{
_action();
}
How can I remove the DB requirement???
I would recommend extracting your MyDbContext into an interface IMyDbContext, and then creating a TestDbContext class that will also implement SaveChanges the way you have it up there, except with returning a random value (like 1) instead of actually saving to the database.
At that point then all you'd need to do is to test that, in fact, all of the entities got their version number upped.
Or you could also do the examples found here or here, as well.
EDIT: I actually just found a direct example with using TimeStamp for concurrency checks on this blog post.
It's my opinion that you should not try to mock this behaviour to enable "pure" unit testing. For two reasons:
it requires quite a lot of code that mocks database behaviour: materializing objects in a way that they have a version value, caching the original objects (to mock a store), modifying the version value when updating, comparing the version values with the original ones, throwing an exception when a version is different, and maybe more. All this code is potentially subject to bugs and, worse, may differ slightly from what happens in reality.
you'll get trapped in circular reasoning: you write code specifically for unit tests and then... you write unit tests to test this code. Green tests say everything is OK, but essential parts of application code are not covered.
This is only one of the many aspects of linq to entities that are hard (impossible) to mock. I am compiling a list of these differences here.
I'm new to Moq, and just started on a project that's already in development. I'm responsible for setting up unit testing. There's a custom class for the DatabaseFactory that uses EnterpriseLibrary and looks like this:
public Database CreateCommonDatabase()
{
return CreateDatabaseInstance(string.Empty);
}
private static Database CreateDatabaseInstance(string foo)
{
var database = clientCode == string.Empty
? DatabaseFactory.CreateDatabase("COMMON")
: new OracleDatabase(new ClientConnections().GetConnectionString(foo)));
return database;
}
Now, here's where that gets used (ResultData is another class of the type DataSet):
public ResultData GetNotifications(string foo, string foo2, Database database)
{
var errMsg = string.Empty;
var retval = 0;
var ds = new DataSet();
var sqlClause =
#"[Some SELECT statement here that uses foo]";
DbCommand cm = database.GetSqlStringCommand(sqlClause);
cm.CommandType = CommandType.Text;
// Add Parameters
if (userSeq != string.Empty)
{
database.AddInParameter(cm, ":foo2", DbType.String, foo2);
}
try
{
ds = database.ExecuteDataSet(cm);
}
catch (Exception ex)
{
retval = -99;
errMsg = ex.Message;
}
return new ResultData(ds, retval, errMsg);
}
Now, originally, the Database wasn't passed in as a parameter, but the method was creating a new instance of the DatabaseFactory using the CreateCommonDatabase method, and using it from there. However, that leaves the class untestable because I can't keep it from actually hitting the database. So, I went with Dependency Injection, and pass the Database in.
Now, I'm stuck, because there's no way to mock Database in order to test GetNotifications. I'm wondering if I'm overly complicating things, or if I'm missing something. Am I doing this the right way, or should I be rethinking how I've got this set up?
Edit to add more info*****
I really don't want to test the database. I want the Data.Notifications class (above) to return an instance of ResultData, but that's all I really want to test. If I go a level up, to the Business layer, I have this:
public DataSet GetNotifications(string foo, string foo1, out int returnValue, out string errorMessage, Database database)
{
ResultData rd = new data.Notifications().GetNotifications(foo, foo1, database);
returnValue = rd.ResultValue;
errorMessage = rd.ErrorMessage;
return rd.DataReturned;
}
So, originally, the database wasn't passed in, it was the Data.Notifications class that created it - but then again, if I left it that way, I couldn't help but hit the database to test this Business layer object. I modified all of the code to pass the Database in (which gets created a the web's Base page), but now I'm just not certain what to do next. I thought I was one unit test away from having this resolved, but apparently, either I'm wrong or I've got a mental roadblock to the right path.
You should be able to create a mock Database object if the methods in it are virtual. If they are not, then you have a little bit of a problem.
I don't know what type "Database" is, but you have a few options.
If you own the source code to Database, I would recommend extracting an interface IDatabase, rather than dealing with a Database class type. This will eliminate some complexity and give you something extremely testable.
If you don't have access to the Database class, you can always solve this with another layer of abstraction. Many people in this case use a Repository pattern that wraps the data access layer. Generally speaking in this case, most people leave testing Respository classes to integration tests (tests without any isolation), rather than unit tests.
Here's how you'd setup your test using option #1:
[TestMethod]
public void GetNotifications_PassedNullFoo_ReturnsData()
{
//Arrange
Mock<IDatabase> mockDB = new Mock<IDatabase>();
mockDB.Setup(db => db.ExecuteDataSet()).Returns(new DataSet() ... );
//Act
FooClass target = new fooClass();
var result = target.GetNotifications(null, "Foo2", mockDB.Object);
//Assert
Assert.IsTrue(result.DataSet.Rows.Count > 0);
}
My dataset code is a little rusty, but hopefully this gives you the general idea.
Based on the code you've given, I would think you would want to talk to the database, and not a mocked version.
The reason is that your GetNotifications code contains DB-specific instructions, and you'll want those to pass validation at the DB Engine level. So just pass in a Database that is connected to your test DB instance.
If you took the testing abstraction to a higher level, where you built unit tests for the database call and a version of this test that used a mocked database, you'd still have to run integration tests, which ends up being triple the work for the same amount of code coverage. In my opinion, it's far more efficient to do an integration test at tier borders you control then to write unit tests for both sides of the contract and integration tests.