CSLA simple unit testing

CSLA simple unit testing

Old forum URL: forums.lhotka.net/forums/t/9566.aspx

j0552 posted on Wednesday, September 22, 2010


I'm struggling with how to do some unit testing with CSLA. Most of my BOs use Linq to SQL in the DataPortal_xyz methods, somewhat like the ProjectTracker examples.

Is it possible to create unit tests without modifying the BOs? I assume not unless I was to use TypeMock. A developer licence is $799.00. That's way outside my budget!

I'm really only concerned with testing the BO and any child objects. There could be validation using CommandObjects which access the database. Also I think I need a way of setting up a custom BusinessPrincipalBase object too.

Are there any examples of unit testing with something like the ProjectTracker samples? What can you recommend? 



tmg4340 replied on Wednesday, September 22, 2010

Realistically, you have to build your BO's to be "testable" at the start.  The ProjectTracker example does not do that, so in that sense it's not a good template to use.

In your case, that means (at a minimum) moving your LINQ-to-SQL code out of your BO DP methods and into a separate DAL.  However, getting testability that's "simple" mean you'll want to build that DAL such that you can build out a mock DB layer in your unit tests, which generally means you need to put a set of interfaces "in front" of your real DAL coding.  That way, when you create your test cases with NUnit, MSTest, or whatever, you can inject your mock objects as your DAL instead of your real ones.

FWIW, Rocky's MVVM videos show how to do this pretty neatly using Bxf.  The videos talk about testing the ViewModel, but the same basic principles would apply here.


- Scott

xAvailx replied on Wednesday, September 22, 2010

Well, what I do is use a unit testing framework, but do integration testing. Part of our build scripts creates a database with test data for testing. Then we use a Transaction Rollback to rollback the data to a known state. Some unit testing frameworks have this built in with a Rollback attribute. It's worked really well for us even in very large projects with over 3000 unit tests (takes about 4-6 minutes to run all the tests). Personally, I find integration testing to be more useful/valuable in terms of time spent vs unit testing (personal opinion, definitely not in the majority..)


triplea replied on Thursday, September 23, 2010

If the issue with testing is how to mock the DB I think this is covered in the Data Access vieo: http://download.lhotka.net/Default.aspx?t=SLVid0106

But otherwise I am also in favour of integration testing the way xAvailx described it. It does take longer (around 10-15 min for the full ~3000 unit tests) but I did not really optimise them so there might be ways of reducing the times. It does allow for thourough testing though and the results are really good.

j0552 replied on Thursday, September 23, 2010

Hi there

I guess it would be too much work now to move the Linq to SQL stuff out of the DP methods and create the necessary interfaces to mock the DAL properly.

I think the xAvailx approach should work very well for our application. The only downside I see is a delay in running the tests which is more than compensated for by not having to modify the BOs.

Thank you.

ajj3085 replied on Thursday, September 23, 2010

I had to do this myself actually.  Its not too much trouble.  Basiclly you create an interface like this:

public interface IDataBase : IQueryable<Table1> { get; } IQuerable<Table2> { get; } void SubmitChanges(); void InsertOnSubmit<T>(T entity); // etc. }

You would also need something  like ContextManager, but instead of DataContext return IDataBase.  This is likely where you'd also use something like StructureMap to create the concreate instance.

It seems to work pretty well so far.

Copyright (c) Marimer LLC