Question

I’ve asked about how to inject stored procedures support when working with Views in SQL Server.

How to use stored procedures in NHibernate for Create/Update when working with database view

Here’s a piece of mapping file:

    <sql-insert>
        exec sp_cycle_insert ?,?,?
    </sql-insert>
    <sql-update>
        exec sp_cycle_update ?,?,?,?,?,?
    </sql-update>
    <sql-delete>
        raiserror ('Cycle can not be deleted', 10, 1)
    </sql-delete>

So, I’ve done the refactoring, etc, and I run my tests…. All failed.

There reason is that SQL Server has view & stored procedures, whereas every time I run a test I set up database from scratch with:

        new SchemaExport(configuration).Execute(false, true, false);

I thought about possible solution and here there are: is there a way to:

• run additional scripts (I guess that is the solution) with stuff needed by database (like stored procedures, view etc)

On the other hand, running scripts can fail (currently I use sdf files, but what if I change to different provider in the future?). Also procedures/views use WITH construction as well as some SQL Server 2005 functions that can be not supported by database used during testing.

• . So I though that it’s time to mock repositories. But also here I see obstacles: views compute some readonly properties and NHibernate accesses backing fields using:

access=”nosetter.camelcase”

If I switch to mocking the repository, I would be responsible for implementing view’s logic in code. Are there any other solutions? Or I’m in big trouble!?

Answer 1

run additional scripts (I guess that is the solution) with stuff needed by database (likestored procedures, view etc)

Use IAuxiliaryDatabaseObject object(s) for this. It’ll contain extra script to run when creating/dropping your schema using SchemaExport. This/these objects you pass in to your NH Configuration object (AddAuxiliaryDatabaseObject).

So I though that it’s time to mock repositories. But also here I see obstacles: views compute some readonly properties and NHibernate accesses backing fields using

You should probably do both. Do integration tests against your real database to verify that your infrastructure/DAL/whatever-you-call-it layer works. In higher layers your probably want to write unit tests instead where things like repositories are mocked.
If I understand your question correctly you have problems setting up your test state because some data is private on your entities? That’s not really an “issue” caused by NH/repos/data acess, but a general one. There are different ways to solve that, you can; relax your API to make it more testable, have an ctor accepting all data, use reflection one way or the other, let your entity’s interface be readonly but its implementation have setters etc etc etc. It’s hard to give general recommendation but try to find a way that suits your case.