@Tristaan, I was thinking from the stakeholders' point of view. I agree that more emails makes sense for testers, and will update my answer accordingly. @Aruna, what form would this test report take? If it's emailed for every test run including successes, then you run into the "I get too much email, I will just ignore this" issue again. If you are sending emails for failures only, I would definitely recommend including a link to the online test results there.

@Laura, if you make that a separate question, I'll vote it up. I think it deserves its own replies.

It might help to post these as separate questions, or collapse them into a question about whether there are practices in testing that are inherently non-Agile.

What is the question? Why does QuickWatch say this?

Went over this with the developer, and it sounds like in order to use the typed objects, etc., we'd need to have an interface we could include to get code to compile :( Instead I'll provide an interface for inclusion in SUT test projects. The SUT test project will include the only the fixture interface and fixture implementations. Then I'll use Reflection in my test harness code to load the implementations of the interface and execute them. I have access to their solutions in source control, so can set up the test projects myself. Getting interfaces from devs, not so easy.

Thanks, that's what I was looking for. I think I'm trending in that direction right now. The dev has some code snippets already available that I can borrow (I'm pretty lousy at Reflection). Can you edit your answer to include your comment? I'd like to have it be a bit more visible for anyone else looking at this question in the future :)

Yeah, I strongly suspect that I will be maintaining fixtures partly to avoid this sort of dependency on the developers. So, it sounds like the fixtures in your system dynamically load the production code, but are all in their own solution? Thanks, this is helpful.

And, thanks much for including your source code

So far, what we are doing sounds similar - except it looks like all your tests can be executed without knowing anything about the SUT's actual code (e.g., by going through the browser). Am I right? What about testing a .dll that was going to be part of a larger system? Would you include every .dll you are testing in your test solution, or put your actual test code into the .dll solution? or would you create multiple solutions for collections of related .dlls that you are testing that include the .dll and your tests, and have your harness dynamically load their compiled code at runtime?