To first answer your question: Yes, they are definitely a part of Continuous Integration if you're asking me. But I think we need to clarify what integration tests are.
Martin Fowler was talking about continuous delivery as a way to automate the complete build process to deploy rapidly. This requires developers to get rapid feedback provided by the Continuous Integration process. So he defines stages that the build should go through:
- a commit build
- thorough testing
The commit build should not take longer than 10 Minutes he states, because of the rapid feedback for developers.
Here is how I see things:
In the first step, fetch the latest commit and build it. If this is successful, you run your unit tests to find out if your classes/class groups are working as defined and expected.
When this is successful you get to the integration test part. Here you test interaction of the just successfully tested units. This involves feeding the units with input and watching their state/interaction/output. Remember that we are still in the commit build, so we want this to be fast as well. So interactions with the file system, a database, network peers and the like have to be stubbed for rapid execution. Martin Fowler also hints the use of in-memory-databases if you require them, just to keep execution on the CI server fast.
After you made sure that the units are working and interacting as required, you usually want to find out about test coverage (just testing a small subsystem usually just isn't enough) and make the tested artifacts available for functional testing/QA/deployment (read: thorough testing) if you think you tests cover enough of your program. Just then, you provision a test environment that mirrors the production environment you are targeting and run tests that involve a real database, real files, real network peers, etc.
In the end, integration tests are about code changes. You want to make sure that the changes you made are not breaking the current system, meaning they integrate well. To find out if they are, you need to make sure that they behave correctly in themselves, then if they interact correctly with their dependencies, and if they were tested at all. You can be quiet confident about your system after you passed all those tests.
If later stages find any problems with your program (like when your database returns a certain value, your network connection will halt) you should try to get these tests stubbed out in the integration tests. The commit build most likely is faster than QA ;)