Should integration tests use database? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 2 years ago.

Improve this question

I know that integration tests test parts of project that interaction with each other somehow. And I need to test this interaction. And there is the question:

1)Should these tests use real database data? I mean I'll have to connect to a real database?

2)I suppose I cannot use common database, I should use my private database for this but my colleges cannot use my tests because they won't have my database. What to do then?

3)I'll have to pass real data to controllers or I can come up with random data? Same question to database data. If real than I'll need to get data from browser and the other things...

4)Do I really need these integration tests if I tested this interactions in unit tests? I just used mocks instead of real data.

5)Won't it be system testing instead of integration?

6)Do integration tests must use real data everytime?

Answer 1

1) Should these tests use real database data? I mean I'll have to connect to a real database?

If you're testing the integration between your software and the database, then yes you should use the real database (ideally down to the version you will be using in production). If the database isn't supposed to be part of your tests, you might be able to substitute some other storage mechanism (might be possible if you use an adapter pattern or a database abstraction library). Note that if you manually write queries, the SQL is likely database dependent so you cannot substitute a different database.

2) I suppose I cannot use common database, I should use my private database for this but my colleges cannot use my tests because they won't have my database. What to do then?

The database used for testing should only be used for that test during the test run. Afterwards it can be cleared and used for another test run. Therefore, you do need dedicated test databases. Ideally this DB runs locally on your development machine, but managing them centrally would also work (might even be necessary if you have to comply with proprietary licenses).

Because your software will run with different production and test databases, you need the specific database to be configurable – e.g. by reading a connection string from an environment variable. Do not put any information that differs between environments into config files if those config files are checked in to version control. Instead, implement a way to use private configurations, e.g. by providing the config as a command line argument or as environment variables. It is of course OK to check in config templates or configs for specific environments, e.g. the production config.

3) I'll have to pass real data to controllers or I can come up with random data? Same question to database data. If real than I'll need to get data from browser and the other things...

You may not be allowed to use real data due to legal constraints, e.g. privacy regulations such as HIPAA or GDPR. There's also the risk that real data could accidentally cause real-world actions if your testing setup is buggy, such as sending out emails or incurring charges for third party systems.

Instead, prefer simulating a scenario and using that data. If your software has a user interface you could manually play through a scenario and capture this data to replay it later. I've also gathered test data by parsing debug-level log files and manually scrubbing them from any personal data (e.g. exact timestamps, IP addresses, names, emails, …).

4) Do I really need these integration tests if I tested this interactions in unit tests? I just used mocks instead of real data.

If you used mocks you tested one half of the interface, but not the integration of both halves interfaces. This is like testing that an electric socket has power, and testing that a plug has the correct shape, but not testing whether the device runs when you plug it into the socket.

Unit tests are very useful to carefully test some component in isolation, but they are usually not suitable as a primary testing strategy. Especially for web apps, it is usually much easier to run end to end tests (possibly on the scale of integration or system tests). Relevant browser automation tools are widely available, and even more tools if you just need to test a REST API.

5) Won't it be system testing instead of integration?

A integration test integrates some but not all components, others will be replaced by stubs. A system test includes all real components. Typically, integration tests still exclude third party services and only integrate local components.

Answer 2

You need to consider what parts of the system you are testing together.

Is this just validating the code you have written performs the correct actions on top of some arbitrary data that is returned? Are you testing the edges of your service to check that the correct query is formed to external services and the response to your client is formatted correctly?

In the case of testing only the code you have written it can be useful to mock the external dependencies of your application and create some scenarios for expected calls to those services. You can then return a canned response if that dependency receives a correct request.

So perhaps when your application calls a database, your DB client can be mocked and you can check if you receive a query of Select * from Orders where product_name = 'foo' and then return some set of Orders that would be representative of the actual response your database would give.

Tests run in roughly this fashion:

• Make call to application API
• Run usual production logic
• Mocked external dependency receives a call for something
• Assert the external call is correct, then return a pre-made response
• Assert the response of the application is the same as expected

Abstracting your application hosting through OWIN allows you to create an in-memory instance of your application and by overriding your Container with mocks you can achieve this quite elegantly.

https://www.strathweb.com/2013/12/owin-memory-integration-testing/