TestUnitOfWork

I am trying to use TestUnitOfWork to isolate Lightspeed from having to hit a database in my unit tests.

I have a relatively simple case with the following:

var user1 = EntityFactory.Create<User>(EntityState.Default);
user1.Username = "test";
var user2 = EntityFactory.Create<User>(EntityState.Default);
user2.Username = "test";
var user3 = EntityFactory.Create<User>(EntityState.Default);
user2.Username = "differentuser";

var expectedUsers = new List<User> { user1, user2, user3 } as IList<Entity>;

IUnitOfWork uow = new TestUnitOfWork();

uow.SetExpectedCollectionResults(expectedUsers);

var test = uow.Query<User>().ToList();

I expect by now that the test variable should hold a list of 3 users. Instead, it fails miserably with the following:

System.NullReferenceException : Object reference not set to an instance of an object.
at Mindscape.LightSpeed.Testing.TestUnitOfWork.Find(Query query, IList results)
at Mindscape.LightSpeed.UnitOfWorkBase.Find(Query query)
at Mindscape.LightSpeed.Linq.Plan.SingleQueryPlan.ExecuteImmediate(IUnitOfWork unitOfWork, Type returnType)
at Mindscape.LightSpeed.Linq.LinqQueryProvider.Execute(Expression expression)
at Mindscape.LightSpeed.Linq.LinqQueryProvider.System.Linq.IQueryProvider.Execute(Expression expression)
at Mindscape.LightSpeed.Linq.LinqQuery`1.GetEnumerator()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList(IEnumerable`1 source)
at UserTests.Should_Return_UserOverview()

Is this a bug with Lightspeed or am I doing something wrong?

I've tried to find some examples of how to use the TestUnitOfWork class both on Google, in the documentation and the samples provided, the test methods in the samples however don't ever use this class. The sample unit tests never use this class, which i find rather weird, as its sole purpose is to use it in unit tests... Could you kindly provide some proper samples on how to use this class?

Greetings,

Safurudin

The problem is in this line:

var expectedUsers = new List<User> { user1, user2, user3 } as IList<Entity>;

This will always set expectedUsers to null, because C# lists are not covariant: an IList<User> is NOT an IList<Entity>.  (Try replacing the "as" with a cast and you'll see the exception.)

Change the line to the following:

var expectedUsers = new List<Entity> { user1, user2, user3 };

Did as you suggestion Ivan, but am still getting the Nullreference,

here is the revised code:

   _unitOfWork = new TestUnitOfWork();
            var user1 = EntityFactory.Create<User>(EntityState.Default);
            user1.Username = "test";
            var user2 = EntityFactory.Create<User>(EntityState.Default);
            user2.Username = "test";
            var user3 = EntityFactory.Create<User>(EntityState.Default);
            user2.Username = "differentuser";
 
            var expectedUsers = new List<Entity> { user1, user2, user3 } ;
 
            var test = _unitOfWork.Query<User>().ToList();

Oh nevermind, I forgot to setup the SetExpectedCollectionResult of course :)

Thanks for the feedback Ivan

OK - I've discovered a new bug

The following:

 _unitOfWork = new TestUnitOfWork();
            var user1 = EntityFactory.Create<User>(EntityState.Default);
            user1.Username = "test";
            var user2 = EntityFactory.Create<User>(EntityState.Default);
            user2.Username = "test";
            var user3 = EntityFactory.Create<User>(EntityState.Default);
            user2.Username = "differentuser";
 
            var expectedUsers = new List<Entity> { user1, user2, user3 } ;
            _unitOfWork.SetExpectedCollectionResult(expectedUsers);
            _unitOfWork.SetExpectedCountResult(2);
 
            var test = _unitOfWork.Query<User>().First();

passes just fine and test variable will be populated.

However altering the last line to 
 var t = _unitOfWork.Query<User>().Where(u.Username == "test").First();

produces the following:

LINQ needs to know which database you think you're connecting to (because CLR expressions translate to operator or function names differently on the different databases).  Therefore, the unit of work needs to be associated with a LightSpeedContext.  Normally, this isn't an issue because the UOW is created from a LightSpeedContext so it's already set up.  However, that doesn't happen with the TestUnitOfWork.

The easiest way around this is just to set the TestUnitOfWork.Context property:

_unitOfWork = new TestUnitOfWork { Context = new LightSpeedContext() };

It should be okay to use an empty context because the TestUnitOfWork never actually issues a query, so it doesn't matter if the LINQ provider chooses the 'wrong' translations for your real database.

We should probably make TestUnitOfWork automatically assign itself a dummy context so you don't run up against this, but this will solve your problem for now.   Thanks for drawing our attention to this!

OK - will try this.

As i mentioned earlier, to demonstrate proper use, this would probably be a nice part of the samples package. Also, do you have documented some kind of "good practices" with regards to using the contexts, unitofwork and the various methods and overloads - tradeoffs and benefits... if not, this could perhaps be a nice series of blog posts - just a tip :)

Thanks for the feedback