none
Is the issue i found with MSTest (2008) fixed in MSTest (2010)

    Question

  • Sorry for the bad subject it i can't quite sum up what i'm going to ask in one line. Anyways, i started to casually use MSTest back in 2008 wanting to start to fully implement it where i work. There was one major issue i ran into which ultimately made me choose xUnit instead. I'm curious if this issue has been addressed. Here is the actual post where i reported the issue on stackoverflow:
    http://stackoverflow.com/questions/1371083/very-basic-structuremap

    Here is where i found a blog that described the issue:
    http://devlicio.us/blogs/derik_whittaker/archive/2008/07/23/mstest-why-i-hate-you-you-cause-me-too-much-friction.aspx

    I was trying to use structuremap. I was using a config file for structure map.  Whatever directory MSTest uses to copy the files from your build directory. For some reason in the past MSTest would not copy .config files. Is it easier to specifiy extra files to copy, or does MSTest copy all files (which it probably should if your still going to run it from a different directory), or have you changed it so the test will run from the build directory like all other testing frameworks (i think mstest should also being doing this)?

    Also, even when the .config file was copied there was still an issue because mstest sets it working folder to:
    c:\<InstallBase>\Microsoft Visual Studio 9.0\Common7\IDE and stuff will generally be looking in the working folder for whatever they need.

    There are a lot of advantages to MSTest including the integration of the IDE and code coverage. I'm also excited at some of the new functionality in 2010 but to me this is a glaring issue and hope it was fixed. If not unfortunately will be sticking to xUnit.

    thanks,
    Choclabs
    Wednesday, March 10, 2010 3:43 AM

Answers

  • Choclabs,

    This are did not change in VS2010, the behavior is the same as in VS2008.

    The simplest workaround, as you already found, is to add a deployment item, either on the test or test class with [DeplymentItem] attribute or in test run config.

    Here's clarification on the questions. Note that below I refer to deployment, which can be disabled by doing main menu->test->edit test run configurations->local test run->deployment->enable deployment.

    - Does mstest copy .config files?
      That depends. When deployment is enabled, mstest copies application configuration files: app.config and <test assembly>.dll.config to the out directory under TestResult dir. It does not copy other .config files.
      When deployment is disabled, no config files are copied anywhere, deployment items are ignored.
    - What is current directory when my test runs?
      Current directory in both cases, when deployment is enabled and when it's not, is the out directory under test results.
      One of the issues is that you can have tests from more than one assembly which can be located in diffent directories. We don't change current directory multiple times while tests are run (although we could), so which one to use is undefined.
      When deployment is enabled, all test assemblies are copied to the out directory, so that's the same as test. But you may need to add some files as deployment items to make sure they are copied there as well. By default test assemblies+dependencies, application configuration files, application satellite assemblies and symbol files for these are deployed automatically
      When deployment is not enabled, tests are loaded from original place, such as bin\debug under test project. Current directory in this case is still out dir under test results.

    Can you please open http://connect.microsoft.com issue for this? This way it will be on our radar for v.next/service pack.
    Possible fixes could be making sure that current directory is one where test assembly is located and deploying files marked as "copy local" = true in test project.

    Thanks,
    Michael Koltachev,
    Visual Studio Team Test

    Thursday, March 11, 2010 5:58 PM

All replies

  • Choclabs,

    This are did not change in VS2010, the behavior is the same as in VS2008.

    The simplest workaround, as you already found, is to add a deployment item, either on the test or test class with [DeplymentItem] attribute or in test run config.

    Here's clarification on the questions. Note that below I refer to deployment, which can be disabled by doing main menu->test->edit test run configurations->local test run->deployment->enable deployment.

    - Does mstest copy .config files?
      That depends. When deployment is enabled, mstest copies application configuration files: app.config and <test assembly>.dll.config to the out directory under TestResult dir. It does not copy other .config files.
      When deployment is disabled, no config files are copied anywhere, deployment items are ignored.
    - What is current directory when my test runs?
      Current directory in both cases, when deployment is enabled and when it's not, is the out directory under test results.
      One of the issues is that you can have tests from more than one assembly which can be located in diffent directories. We don't change current directory multiple times while tests are run (although we could), so which one to use is undefined.
      When deployment is enabled, all test assemblies are copied to the out directory, so that's the same as test. But you may need to add some files as deployment items to make sure they are copied there as well. By default test assemblies+dependencies, application configuration files, application satellite assemblies and symbol files for these are deployed automatically
      When deployment is not enabled, tests are loaded from original place, such as bin\debug under test project. Current directory in this case is still out dir under test results.

    Can you please open http://connect.microsoft.com issue for this? This way it will be on our radar for v.next/service pack.
    Possible fixes could be making sure that current directory is one where test assembly is located and deploying files marked as "copy local" = true in test project.

    Thanks,
    Michael Koltachev,
    Visual Studio Team Test

    Thursday, March 11, 2010 5:58 PM
  • Thanks for the reply Micheal. Ya i thought connect was only for bugs and since this was an implementation decision i thought i couldn't report it there but i definitely will now since i know its ok to do so. I hope it gets fixed in the next SP. After i create the connect issue i will report it back here so anyone can reference it. I will also notify the original author of the blog. The more people the more likely it will be resolved quickly :).

    thanks again,
    Choclabs
    Friday, March 12, 2010 5:26 AM