I'm working in a primarily Windows / .NET system. I've written a test framework in C# that includes a test harness that runs fixtures (anything that implements the ITestFixture interface). These fixtures are the interface between my framework and the SUT (System Under Test), and sometimes they have dependencies on SUT methods or objects. Nothing else in my framework depends on the code of the SUT. I am testing multiple projects, which have relatively little to do with each other, and will be testing more and more over time.
Right now, I have a test solution in .NET that has all of my test framework code . . . and all of the fixtures, and all of their dependencies. The result is a giant test framework solution with a ton of dependencies. This doesn't seem like a very good way to do things in the long-term.
Another alternative that we are discussing is having me create a "Common.Test" project that essentially includes the interface for the fixtures, and maybe a few utility functions. Developers would then include a "SUT.Test" project (where SUT is whatever the system under test is called) that includes their fixtures and depends on the Common.Test project. Fixtures would be compiled as part of their solutions, and the test harness would load their fixtures from their .dll files dynamically.
Do either of these options (fixtures in the test solution with tons of dependencies, or fixtures in the SUT code that are dynamically loaded by the harness) sound better than the other to experienced automation testers? Are there other options that I'm missing that should be considered? If you use fixtures, what does your team do?