Should I inject factories as interfaces for unit testing with CSLA?

[sacrejohn]

Hello,

I’m working with the CSLA framework and using factories to access my business objects (BO). The factories encapsulate operations like Create or Get. My code can easily support injecting factories as interfaces, which would simplify testing by replacing real implementations with mocks.

However, my BOs (especially editable ones) directly expose methods like Save, which forces me to also mock the DAL (via DataPortal). This makes me feel like mocking both factories and the DAL is redundant.

Here’s a simplified example:

public interface IBusinessObjectFactory
{
    MyBusinessObject Create();
}

public class BusinessObjectFactory(IDataPortal<MyBusinessObject > dataPortal) : IBusinessObjectFactory
{
    public MyBusinessObject Create()
    {
        return dataPortal.Create<MyBusinessObject>();
    }
}

public class MyService
{
    private readonly IBusinessObjectFactory _factory;

    public MyService(IBusinessObjectFactory factory)
    {
        _factory = factory;
    }

    public void SaveBusinessObject(MyBusinessObject bo)
    {
        var savedBo = bo.Save(); // Direct call to the DAL via DataPortal
    }
}

When writing unit tests, I’m wondering:

• Is it worth injecting my factories as interfaces if I still have to mock the DAL for Save anyway?
• Would it be simpler to avoid using interfaces for factories and focus on testing directly with the DAL (or mocks of the BOs)?
• Are there any CSLA best practices for handling this kind of situation?

Thanks in advance for your insights! 😊

[rockfordlhotka]

@sacrejohn I think it depends on what you intend to test, and whether you are doing unit tests or integration tests.

I typically write unit tests for

1. My actual DAL (below the data portal - so no CSLA involved basically)
2. My rule classes (independent of any properties to which they are attached)

Then I write integration tests for the business layer, typically running against an in-memory "database" using a mock DAL. This test code is basically like the UI code that would be interacting with the domain business types.

Sometimes I've written UI tests, though usually (in my experience) this is done by a dedicated QA group that writes automated tests using a variety of tools (such as Playwright).

It sounds like you are wanting to create UI level tests that run against mock domain objects?

Many years ago, @JasonBock did a bunch of work in this space, and the outcome of that is that all the root base class types (like BusinessBase) implement an interface corresponding to that type. The interfaces are quite large because they include the entire public API for that part of CSLA - with the intent that you can use something like Rocks for mocking the domain types.

You can also mock IDataPortal<T> to avoid actually executing your logical server-side code.

Again, what I personally do, as a general rule, is to create a mock in-memory database. Either by hand or by using the in-memory features of Entity Framework. This way I avoid mocking the domain classes or the data portal, and allow the UI integration tests to execute against a "real" database with a guaranteed known starting data set for each run (because it is in-memory).

[sacrejohn]

Hello,

First of all, I want to say that I really appreciate CSLA and find the framework incredibly powerful for building robust applications. However, one point that often comes up with new members of my team is unit testing. They sometimes feel that CSLA makes unit testing more complex.

Personally, my approach has always been to focus on integration tests, mocking the database (or not) to ensure everything works correctly end-to-end. However, I've noticed that younger developers, who are used to "mocking everything" in their unit tests, struggle to adapt to this philosophy. Their first instinct is often to try to "mock CSLA," which, in my opinion, is neither a good idea nor easy to do.

I’m reassured to see that your response confirms my current approach. It strengthens my belief that investing in solid integration tests is far better than attempting to mock core components like those in CSLA.

Thank you again for your work and responsiveness in the community!

[JasonBock]

FWIW, even as the author of the aforementioned Rocks framework, I generally avoid using mocks
generated by frameworks unless the situation presents itself that it's the "best" approach. For example, I typically don't mock IMemoryCache because new-ing up an instance of MemoryCache in a test is very easy to do.

When I've used CSLA in the past (and I mean a decade or farther in the past), it was really hard to any kind of "isolated" unit testing. This was really problematic if large object graphs were in play. Long story short, with changes in CSLA, that became easier to do, but still not ideal. I haven't had to do that in a while though, so maybe things have changed?

If you can test your classes isolated, IMO that is the ideal thing to do, but that's not always easy.

[Chicagoan2016]

@JasonBock I am glad your website is online : ).
I can't seem to find the article (and code) you wrote for 'dirty property' tracking in Csla.
Regards