We Keep Coding

C# unit testing MoQ, Mock DB context, issue when transactions are used

I need to write unit testing for legacy code. I'm using MoQ for wring DB Context based unit testing. One repository method contains saving 2 entities in a transaction.
And when the test execution hit the dbContext.Database.BeginTransaction() it gives the error "No connection string named 'LimaV3DbContext' could be found in the application config file".
It seems the test trying the execute the actual db context rather than using the mock db context. Is there a way to force the test execution to use the mock db context used in the test initialization.
I've setup the tests based on the following article.
https://learn.microsoft.com/en-us/ef/ef6/fundamentals/testing/mocking

Testing with AutoFixture with real Database without mocking

I am developing an ERP that is not based on EF. My question is: how can I do perform test using AutoFixture for all the CRUD without using doing mocking? How can I perform cleanup and Setup operation for Unit Test.
Likewise, I need to test update and delete operation alone with insert. What I have seen on different site there are only insert fixture examples without using mock.

Mocking calls to SQL Server Stored Procedures?

I am implementing an interface into a C# class, whose entire job is basically just to call some T-SQL stored procedures and return the data. Other implementations of the interface may obtain data through web-services, reading files, etc, so to test this particular class I'd ideally mock an SQL Server database and its procedures.
I'm not sure if this is feasible. I've seen tools like RhinoMock used to mock database tables but since the entire purpose of my code is to talk to a DB, can I mock the entire DB or is that a bit of a waste of time? I'd ideally like a way to transparently provide a replacement for having a real DB so local testing can be done, making real stored-procedure calls against a fake DB.

If you are building unit tests then you should not execute the stored procedure and you should stub this interface.
If you are building integration tests then you must have it all working.
In both cases your class shouldn't do it directly, you should have an inner handler like IDbHandler and during your unit tests you should mock it and during the integration tests you should use your concrete implementation.
The purpose of having a mock is to verify that the other side (DB in your case) got a request with the expected parameters but a physical component can't be mocked so just by adding an interface between your code and the physical component will enable those validations.
BTW I would start with having the unit tests and just afterwards add the integration tests.

Visual Studio 2010 Unit Testing

I am trying to find out in Visual Studio 2010 Unit Testing how to keep a transaction of the data I have either added, updated, or deleted during my tests so on my TestCleanup I can rollback their values.
What search terms should I be using to find more about this?
Cheers
Paul

Why do you need to rollback changes? Are your unit tests updating live data? If unit tests are written properly, you shouldn't have to clean up after what your tests changed because the data they're changing should be isolated to your test.
Edit:
It sounds like you've set up a data set for testing and want to make sure that data set is restored back to its original state. I prefer the practice of setting up the test data as part of the test, but I understand that can get difficult for complex tests.
If this in an ADO.NET data source, you could start a transaction then roll back that transaction at the end of your test. For example:
using (var transaction = db.BeginTransaction())
{
// Do tests here
}
// The transaction is rolled back when disposed
Edit 2:
A third option, if you don't have transaction support, is to have a backup of your test data in a place where it won't get modified, then at the end of the test, restore that backup.

For unit testing you should probably try using mocks instead of accessing a test database. Unit tests should generally be completly self-contained (and not rely on external sources e.g., databases).
If you are actually testing calls to the database then this is probably an integration test in which case you could:
Create test data in setup
Run code
Assert test passes
Remove test data inserted in step one

Best practices to generate schema for production with NHibernate

I am now ready to use NHibernate to persist my data layer access. I used DDD until that point and I use fake for unit tests and for the test site.
I know that I can use SchemaExport for unit/integration tests of my NHibernate concrete repositories but how should I generate the schema to be used for the test site ?
Should I create a special class in my tests that create the schema and insert the static data or should I generate the schema at the launch of the site if the database is not created ?

Personally I like to use a small console application which loads all the mappings and executes a SchemaExport as below:
new SchemaExport(config).Execute(ddlScript => {
using (var writer = new StreamWriter(fileName, true))
{
writer.Write(ddlScript);
writer.Flush();
}
}, false, false);
This console app runs as a step of the build script and the DDL script file then gets picked up by WiX and is included in the MSI package (which generates the whole database at install time).

As a simple scenario you can miss use a unit test for that. Just create unit test called CreateSchema which will do the schemaexport. Then run it before you will run the other tests.
I have a similar question here on STO

For your full build script I'd go with Markus's suggestion, for just running your unit tests
I'd put
<property name="hbm2ddl.auto">create-drop</property>
in the app config of you test project - this will drop and recreate your schema everytime all the tests are run. Each unit test can add the data it needs to test.