Tim Bassett

We are having a number of usability issues with using mstest in the IDE (developers) and our CI process (build masters). We can pretty much come up with a solution for either side, but any solution good for one side impairs the other side.

The most significant challenge came up recently. I decoupled an assembly with concrete implementations of some interfaces we have defined. Upon doing this, I removed references to this assembly containing the concrete classes. The 1st problem this brought up is that we need to manually get the derefenced assembly into the directory where the unit tests execute (Unit Tests\...\Out).

Problem 1: We have a localtestrun.config in the solution, I go to put it into there, do I choose the debug/release bin folder
Problem 2: What about the dereferenced assembly's dependendencies I could include the whole directory, but it might copy older versions of something else. I could point them out specifically, but then it is a static list that may get out of date.

Other problems mstest and the localtestrun.config are presenting for us:

IDE Performance problem: We have 50 or so test assemblies, xyz may need these 20 files, while abs may need those 10 files. Everytime we run our xyz tests we also have to copy the other 10 files, needlessly.

We have considered the possbility of multiple configs, but that makes the CI process arduous.


Can anyone provide direction for any the three above problems and how we might solve them


Re: Visual Studio Team System - Testing mstest - woes continuous integration - scalability

Nagaraju Palla MSFT

Hi Tim,

Problem#1: do you know the active configuration of the dereferenced assembly while it was part of the solution file You should use the same version to deploy through run configuration file.

Problem#2: the test exectuion automatically copies all dependent assemblies into deployment folder, so you shouldn't need to do anything.

Performance problem: the run configruation file is kind of global setting, so it deploys all items irrespective what tests are chosen to run. However, you can deploy items to specific tests - to do this:

    1. remove the deployment section from test run configuration file
    2. open the 'Test View' in VS and choose the test XYZ
    3. select 'Properties' from the context menu
    4. select 'Deployment Items' property from properties window and enter the 20 files this test is referring to.

You can use the combination of run configuration file and deployitem property of test and should be able to acheive better performance.






Re: Visual Studio Team System - Testing mstest - woes continuous integration - scalability

Tim Bassett

>>Problem#1: do you know the active configuration of the dereferenced assembly while it was part of the solution file You should use the same version to deploy through run configuration file.<<

It is still part of the solution. The run config file is used in both the debug and release version of the test run, so there is no way to do that I know of.

>>
Problem#2: the test exectuion automatically copies all dependent assemblies into deployment folder, so you shouldn't need to do anything.<<

The assemblies are no longer a dependency, that was the whole point of dereferencing them.