Injecting dependencies into tests

Question

Usually when using dependency injection, unit (and other) tests are responsible for creating/mocking dependencies of the system-under-test and injecting them.

However, sometimes the test itself has dependencies, or needs to inject dependencies into the SUT that it can't itself create. For example, when testing classes which interact with a database, the test needs to know connection strings and catalog names etc., which can't be hard-coded since they aren't necessarily the same for everybody running the test.

So, how would you recommend that a test find out these settings? Do some xUnit-style test frameworks provide a way to give dependencies to a test fixture? Should the test class have static properties you populate before running all the tests? Should the test ignore DI practices and just go and get the dependencies from some global place? Other suggestions?

Answer 1

There's a principle for fully automated tests: you should be able to pull down all the source code from the source control repository and simply run the tests.

Given that the environment (machine) has the correct installation base (i.e. compiler, test framework, database engine if relevant, etc.) the tests are responsible for setting up their Fixture before executing the test cases.

That means that for databases, the tests should

1. create the database in question
2. run its tests
3. delete the database again after the last test case

If, for some reason you can't do that, the only thing you can really do is to have a configuration file in your source control system that contains machine-specific entries for all machines in your testing invironment; e.g. for the machine Tst1 the connection string is one value, but for Tst2 it's another.

This can get ugly really quickly, so it's much easier to have the tests be responsible for Fixture Setup and Teardown, because that means that they can simply use hard-coded values, or values generated on the spot.

This really has nothing to do with DI...