xUnit for test DAL in .net core 2 and DI- a little bit of confusion

Question

I a little bit of confusion about xUnit for test my DAL.

My goal is to verify that my DAL correctly accesses the DB and extract the right data.

I create a xUnit test project and try to do a simpli test with Moq like this

[Fact]
    public void Test1()
    {
        // Arrange
        var mockMyClass = new Mock<IMyClassBLL>();

        // Setup a mock stat repository to return some fake data within our target method
        mockStAverageCost.Setup(ac => ac.GetBy(It.IsAny<MyClassVO>())).Returns(new List<MyClassVO>
        {
            new MyClassVO { HCO_ID = "1"},
            new MyClassVO { HCO_ID = "2"},
            new MyClassVO { HCO_ID = "3"},
            new MyClassVO { HCO_ID = "4"}
        });

        // create our MyTest by injecting our mock repository
        var MyTest = new MyClassBLL(mockMyClass.Object);

        // ACT - call our method under test
        var result = MyTest.GetBy();

        // ASSERT - we got the result we expected - our fake data has 6 goals  we should get this back from the method
        Assert.True(result.Count == 4);
    }

The method above work fine.

Now I want access directly to the db for get data.

Obviously something escapes me, I did not understand how to perform a data test with .net core 2 simulating dependeny injection and accessing the data.

Can someone clarify my ideas?

Answer 1

Are you looking for a unit test or an integration test? They're fundamentally different things and serve different purposes.

If your goal is to ensure that GetBy (the unit of functionality under test) does what it's supposed to do, then you should not be using live data. A real connection with real data would introduce variables, causing the test to potentially fail when there's actually nothing wrong with GetBy. For a true unit test, you should only use mocks and test data.

If your goal is to ensure that your application can connect to your database and actually draw data out of it, then that's an integration test. You might potentially use GetBy/your repository, in general, in the test, but generally you'd want to avoid that. Again, connecting and querying directly with via something like ADO.NET serves to remove variables, so if the test fails, you'll know it was because there actually was a problem connecting/querying, in general, rather than just some issue with your repository or a particular method thereof.

Long and short, a good test tests just one thing. If that particular thing requires external components (such as a SQL Server database), then it's an integration test, and at that point, you're testing the integration of the component. Something like a repository method should not come into play, as that would be testing two different things in one test. If you need to test GetBy then there should be no external dependencies, such as a SQL Server database.

Additionally:

I did not understand how to perform a data test with .net core 2 simulating dependeny injection and accessing the data.

This would be an example of testing the framework, which is another no-no. You can safely assume that DI works in ASP.NET Core. It has its own test suite covering that. There is no need for you to add tests for that as well.