Hi,
I have a Csla business library which is used by a Windows service to syncronize a master database with an application database. I have a list of "things that should be considered for syncing", and I go through that list and for each ROB object I create a Syncronization BO. When that BO is saved, it checks if it's valid in the data portal.
If it is, it does some syncing to both databases (some of the data is two way). If not, it logs the reasons in another table so users can see why the data wasn't synced.
This works ok, but I have problems debugging since I basically have to start both databases, make changes in either one, than watch that the sync happens. I have a controller that runs as an NUnit test to start the threads and stuff... but obviously this isn't an ideal way to test.
What I'm hitting now is that, during the syncing in the DataPortal_Insert, there is some logic that if X and Y are true, then a stored procedure should be called. There are a few of these cases, and the customer is reporting that the procedure isn't being called when they believe it should be.
I'd like to be able to setup a unit test so that I can more easily figure out what's going on, so that I don't rely on the databases at all. For the Sql side I'm using Linq to sql and a custom library for the other database.
Or should I simply create boolean properties and test that they are correct, and assume that the procs will be called provided the bools evaluate properly? Maybe I have too much business logic in the DP_I?
Thanks
There are four data access models supported by CSLA (see the data access FAQ).
Models 2, 3 and 4 allow you to create pluggable data access layers (DALs), which means you could create a mock DAL with test data pretty easily.
If you are using model 1, you might look at switching to model 2, at least for the objects in this use case, so you can create a mock DAL.
Copyright (c) Marimer LLC