Reply
Member
Posts: 1
Registered: ‎02-02-2021

How to Integration Test domain classes that call stored procedures?

Hello dotnet,

Im looking to run integration tests on my domain/core classes(using Core 2.0).

These classes call stored procedures using SqlCommand from Data.SqlClient, passing the name of the stored procedure and the connection string, grabbing the data then parsing the dataset and returning an object.

I was wondering how I would go about integration testing it? should I use a test database separate from my localDB I've been using for testing? Are there any frameworks that make using a database for unit testing fairly easy?

Thanks in advance.

Member
Posts: 6
Registered: ‎02-01-2021

Re: How to Integration Test domain classes that call stored procedures?

My advice is to use test (real) database (depending on the policies in your firm it can be database on a test server or you can use local instance of the database provider on your dev machine .. etc).

The point of the integration tests are to verify that your application is working stable as single unit. The test env. must be as close as possible to the production evn. which means a real database. EF in memory database representation is no good for that.

You can check also component tests . They are like the integration tests, but with them you don't test the application as a unit, but the major components of the application like repositories, services .. etc, on the other side with integration test you will most like test the REST api endpoints(in the context of REST application).

Some notes on integration/component tests

  • In the best case the only thing you will need to change for the test env (your integration tests project). will be the connection string to use the local / test database configuration in the web/app.cofing.
  • No mocks when using integration tests
  • Reset the state of the database before each test. This way you can avoid your database grow in size.

Examples for integration tests

If you are developing REST api (just example). This are very basic test case examples which are not to be taken as 100% best practices. Just to have a glance of what they could be.

  • Test the GET end points with records / no records in the database
  • Test the authorization policies for the different resources
  • Test the POST end points with valid / invalid data
  • Assert the database state, like table counts and the http respose code of the request
  • etc ...

NOTE: In some cases we use the in memory representation only in the begging of the application for some prototyping before we start to develop the actual database.