I was told by a few members here that splitting up my unit tests into different assemblies for different components is the best way to structure unit tests.  Now, I have a few questions about that idea.  What are the advantages of this? Organization, and isolation of errors?Let's say I have a component named calculator, and I create an assembly for the unit tests on calculator.  Would I create a separate assembly for the integration tests I want to run on calculator? Or is the definition of an integration test a test across multiple components, like calculator and whatever else, which would require a separate assembly to test both of them together? In that case, would I have one assembly to do all of the integration testing for every component combination?  
Making Separate Assemblies For Different Types Of Tests For The Same Component?
c#;unit testing;visual studio 2010;qa;nunit
This could be a weird semantic thing, but it sounds like you're equating component to class.  I would normally associate component with assembly.In other words, one unit test assembly per assembly-under-test.  That's a pretty common configuration in my experience.  You do that in order to minimize the number of dependencies your tests have.  Ideally they should only depend on the specific assembly being tested, but even in the worst case scenario, they'll still only depend on indirect dependencies of the AUT.Integration testing is a whole other animal; you'd normally want that to be totally segregated from your unit tests, since an integration test will have all kinds of dependencies folded in from various parts of the application (that's why it's called an integration test...).  Keep those far, far away from your unit tests, otherwise you'll find yourself trying to manage build errors and unit test failures at the same time.  Not fun.