Unit testing vs Integration Testing

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.

http://www.typemock.com/unit-tests-integration-tests

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.