What is the difference between unit testing and integration testing when it come to web development (where 90-95% of the code relies on a database)? One thing I here all the time is that unit testing should not deal with databases and integration testing should. The issue I have with this is that to me that means the only difference between unit testing and integration testing is the data source and if that is the case, you are testing the same functionality. If the functionality that is tested is the same, why even bother with unit testing and always test against a database?

  • I don't believe this is a duplicate of my other question. My other question about about the use of databases in unit and/or integration testing where this question asks what is actually the difference between the two (my other question is based on the assumption that unit and integration testing are the same thing).
    – ryanzec
    Aug 15, 2011 at 21:38
  • 1
    programmers.stackexchange.com/questions/93245/… covers the difference between unit and integration test if that is the focus of this question for another possible duplication here.
    – JB King
    Aug 16, 2011 at 20:10
  • 1
    I didn't find the linked question at all helpful (a good answer to the general question). It is too general. The OP is making the point specifically about database testing and where unit testing fits into database testing, when traditionally testers will focus their testing on the interface and not the database. My problem is that database unit testing is so often not performed ... question to follow, I guess :)
    – Marcus D
    Mar 24, 2017 at 16:43
  • How can the alleged duplicate be a duplicate when the question isn't a real question and only relates to integration tests by being tagged with the integration test tag? Apr 3, 2018 at 11:32

3 Answers 3


Integration testing is about testing the integration points between 2 or more systems, this could be a database, it could be a web service.. whatever it is, it is interaction based, i.e. What happened to my component when it calls a stored proc that does xy and z? Has a web service changed its interface?

Unit testing deals with a single unit of work. Each unit test should test just one thing that method should do, this is where you stub out the database and any external interfaces or interactions.


A unit test is:

Repeatable: You can rerun the same test as many times as you want.

Consistent: Every time you run it, you get the same result. (for example: Using threads can produce an inconsistent result)

In Memory: It has no "hard" dependencies on anything not in memory (such as file system, databases, network)

Fast: It should take less than half a second to run a unit test.

Checking one single concern or "use case" in the system: (More than one can make it harder to understand what or where the problem is when the problem arises.)

By breaking any of these guidelines, you increase the chance of developers either not trusting or not believing the test results (due to repeated false failures by the tests), or people not wanting to run the tests at all because they run too slowly.


Another thing that isn't mentioned above is that it shouldn't rely on any special configuration. Can any developer check out a copy of the source code and run the unit tests?

With a database you require each developer to have the same database configuration set up. What if some of the developers don't work with the database normally?


Unit Testing is all about testing a single component (and thus simpler than integration testing).

Unit test is really good to make sure your public interface does not break during bug fixes. Each class (component) is tested in isolation without using any dependencies (dependencies are usually injected and mocked). Thus you are usually able to test 100% of execution paths (by getting your injected dependencies to give you every different kind of result (including errors)). This would be really hard achieve with a real data source as generating the error responses are hard (e.g. DB how do your force DB exception at the correct point in the test).

Integration tests is about how the components work together.
And as a result can be easier to write but harder to set up to test all possibilities.

Here you write test on how systems of components work together. It test to make sure that you have not deprecated any interfaces that are needed. Stuff like that.

Not the answer you're looking for? Browse other questions tagged or ask your own question.