One of the main advantages of Docker is the isolated environment it brings, and I want to leverage that advantage in my continuous integration workflow.

A "normal" CI workflow goes something like this:

• Poll repository for changes
• Pull from repository
• Install dependencies
• Run tests

In a Dockerized workflow, it would be something like this:

• Poll repository for changes
• Pull from repository
• Build docker image
• Run docker image as container
• Run tests
• Kill docker container

My problem is with the "run tests" step: since Docker is an isolated environment, intuitively I would like to treat it as one; this means the preferred method of communication are sockets. However, this only works well in certain situations (a webapp, for example). When testing different kind of services (for example, a background service that only communicated with a database), a different approach would be required.

What is the best way to approach this problem? Is it a problem with my application's design, and should I design it in a more TDD, service-oriented way that always listens on some socket? Or should I just give up on isolation, and do something like this:

• Poll repository for changes
• Pull from repository
• Build docker image
• Run docker image as container
• Open SSH session into container
• Run tests
• Kill docker container

SSH'ing into the container seems like an ugly solution to me, since it requires deep knowledge of the contents of the container, and thus break the isolation.

I would love to hear SO's different approaches to this problem.