Running tests as usual against docker containers or dockerize tests?

I'm new to Docker and was reading up on Docker. It's a great way to test systems in a self contained and reproducible standardized configuration (when done correctly).

However, in all the things I've read, there doesn't seem to be too much emphasis on how the testing should occur with docker containers. The docker is used to "contain" the infrastructure and application (code) for easy testing (as well as deployment). But sometimes test codebases are be large and not so simple too. And one can have a test codebase for API tests, another for UI, etc.

What is or should be (as determined at some point) the standard practice for testing docker containers/deployments of your applications/infrastructure? Should:

• the test code be deployed the old conventional way, as file repository you pull from somewhere and just then run on Jenkins server/slave or one's localhost for dev/QA testing/debugging, with the tests targeting apps in docker container?
• dockerize the whole test code base as a self contained container and then using that container to launch/execute tests against the other containers that have the app code/system infrastructure?
• combine the tests as part of the individual docker containers themselves to be run when/as needed. But I would think this works best only for unit tests that really pair with the container that holds the matching app code. Integration, UI, system level tests are different in association to app modules within the system.

The only reason I can think of that make dockerizing tests perhaps useful is that it's a single container with all the tests you need and the matching test infrastructure (all the test platform/language dependencies) so that one can deploy and run tests anywhere together with the matching app code containers. Saves one from having to set up test infrastructure when/as needed. But no seems to have blogged about such a thing for dockerized tests.