1

I have a test project which I want to execute from MSTEST. This project has an App.config and a ConnectionString.config files. The ConnectionStrings section is redirected to the later.

<connectionStrings configSource="ConnectionStrings.config" />

When I run MSTEST, the project is built and most of the files are copied, but the ConnectionStrings.config file is not, despite its properties are set to Content and Copy always.

VS2015 File Properties

MSTEST.EXE is run from the project's directory with this (simple?) command line:

MSTest.exe /testcontainer:bin\Debug\Tests.dll /resultsfile:%ts%

Assume MSTest.exe is in the path, it runs, it builds the project and creates a directory like XXXXXXXXXXXX_YYYY-MM-DD HH_MM-SS but the output subdirectory doesn't contain the ConnectionStrings.config file (that should be copied according to the seetings, right?)

Vitalii Pro
  • 313
  • 2
  • 17
Yván Ecarri
  • 1,661
  • 18
  • 39

2 Answers2

1

Can you try to apply [Deployment Item("ConnectionStrings.config")] attribute on you test class?

Ayaz
  • 2,111
  • 4
  • 13
  • 16
1

Edited

So, on VS 2017 Community edition, I decided to try and do a simple test to replicate what you were seeing, and I did. Running it from the IDE, the DeploymentItem attribute worked as expected, but not from mstest. I would have expected that people would have seen this before if it's truly a bug, but maybe people just haven't been trying that out much with VS 2017 yet.

Anyway, what did finally work for me was to create a testsettings file with the DeploymentItem specified there. This is the file I used:

<TestSettings name="Local" id="00ebe0c6-7b64-49c0-80a5-09796270f111" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
   <Description>These are default test settings for a local test run</Description>
   <Deployment>
     <DeploymentItem filename="ConnectionStrings.config"/>
   </Deployment>
</TestSettings>

There's also an outputDirectory attribute if you want to specify that. The DeploymentItem node seems to work just like the DeploymentItem, so the filename needs to be relative to the output directory (assuming you haven't overridden it in the testsettings file you're using; since you already have it copying your ConnectionStrings.config to the output directory, I think this could work for you. Alternately, you could just make it ..\..\ConnectionStrings.config if you didn't want to copy it into your output folder in the build but did want it copied using mstest.

Then just add a /testsettings:<testsettingsfilename> to your mstest command line execution.


Original Post

Unless I'm greatly mistaken, running mstest.exe only runs the already-built test project, and doesn't go back and build the test project (and how could it? It's a testing tool, not msbuild, and you're just pointing it at the test DLL, not the project file). So, if you are just running mstest and not ever building your project from Visual Studio or through msbuild or whatever, the changes that you've been making won't take until you do actually build your project again.

Can you verify that you've actually re-built the test project with that DeploymentItem attribute that SMA referenced (maybe check the last time that your Tests.DLL was updated as a quick first step), and then run your mstest command against the newly-built Tests.DLL? I would expect, based on my own knowledge and this answer about copying a file to mstest's test folder, that you would see your config file copied over into the test run directory, as long as that config file exists in the first place.

Kdawg
  • 1,508
  • 13
  • 19
  • 1
    MSTEST.exe creates a copy of the latest build and runs the tests using it. The problem here is that MSTEST doesn't copy some config files that are in the original buld folder. Yes, I do build the project and yes, the project build has the required files but MSBUILD doesn't copy these fields to the final directory. – Yván Ecarri Jul 20 '17 at 10:21
  • @Y. Ecarri: I was able to reproduce your issue on my machine. I was able to get it to work with a testsettings file; maybe that will work for you. – Kdawg Jul 20 '17 at 13:56