Note that there are some explanatory texts on larger screens.

plurals
  1. POIs there an alternative for using a .testsettings file with TestCases and Microsoft Test Manager?
    primarykey
    data
    text
    <p>We have a peculiar situation here that is causing our automated tests to fail on a newly created lab environment, using TFS 2012.</p> <p>We've always had a bunch of 'unit' tests that tested our DAL code, which in turn uses the <a href="http://msdn.microsoft.com/en-us/library/microsoft.practices.enterpriselibrary.data%28v=pandp.31%29.aspx" rel="nofollow">Enterprise Library Data Application Block</a> to perform operations on the database. This was setup quite a few years ago, to enable our clients to choose either SqlServer or Oracle databases alongside our product, taking advantage of the <a href="http://msdn.microsoft.com/en-us/library/microsoft.practices.enterpriselibrary.data.databasefactory%28v=pandp.31%29.aspx" rel="nofollow">DatabaseFactory</a> class and all the supporting generic interfaces and classes in the entlib.data. I mentioned 'unit' like this because these are actually not pure unit tests but integration ones, seeing as they require a real database to work.</p> <p>To test the same SQL code against both databases, we maintain two separate .config files inside a 'Resources' folder in our TFS project branch, pointing to our test databases:</p> <ul> <li><code>Resources\SqlServer\ConnectionStrings.config</code> (SqlServer specific connection strings)</li> <li><code>Resources\Oracle\ConnectionStrings.config</code> (Oracle specific connection strings)</li> </ul> <p>In the root Resources folder, there are two accompanying .testsettings files, responsible for deploying files specific to each database:</p> <ul> <li><code>Resources\SqlServer.testsettings</code> (which deploys the SqlServer\ConnectionStrings.config file)</li> <li><code>Resources\Oracle.testsettings</code> (which deploys the Oracle\ConnectionStrings.config file)</li> </ul> <p>Since the whole structure is in source control, the testsettings is able to find the .config files by using relative paths, allowing us to test everything without having to setup parameters manually. On devs machines, we always select the <code>SqlServer.testsettings</code> file when running the tests, so that they don't need to have the whole oracle environment installed to validate their changes before checking in the code. The Oracle side of the validation always occurred in our build process, where we actually test every method twice: first using the same <code>SqlServer.testsettings</code> used by the developers, and then using the <code>Oracle.testsettings</code>.</p> <p>This way, we can setup our test assemblies' app.configs to redirect the connectionStrings node to an external file, like this:</p> <pre><code>&lt;configuration&gt; &lt;connectionStrings configSource="ConnectionStrings.config"/&gt; ... </code></pre> <p>When the tests are run, mstest copies the adequate ConnectionStrings.config file to the test's working folder, based on which .testsettings was used to initiate the run.</p> <p>This was working fine until today, when I discovered that <a href="http://social.msdn.microsoft.com/Forums/vstudio/en-US/229fe0b3-5ebc-4e7e-9cd5-c63bbf1f7052/additional-deployment-items-for-automated-codedui-test-started-from-microsoft-test-manager" rel="nofollow">tests started through Microsoft Test Manager ignore the Visual Studio .testsettings files</a>. Now I'm trying to run these same tests in our lab environment but the ConnectionStrings.config files are not deployed (understandably) and the tests fail.</p> <p>How can we achieve this without using .testsettings files? After having huge headaches trying to setup oracle correctly in our new x64 build server, we disabled Oracle tests in the build definition. Now that we started setting up our lab environment, we thought about having one of the machines in it configured with our whole system using Oracle, enabling us to again run these 'unit tests' with oracle-specific connection strings to validate our queries. At the same time, we want to keep testing everything locally and on the build server using SqlServer also.</p> <p>I think using <a href="http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.deploymentitemattribute%28v=vs.80%29.aspx" rel="nofollow"><code>[DeploymentItem]</code></a> in this case is impossible, since it is meant for static files and not selectable, dynamic ones like our current setup.</p> <p>Is there any equivalent to the .testsettings deployment process that we could use with TestCases inside MTM/Lab Env? On the <code>Properties</code> tab for our TestPlan, I can see the <code>Automated Runs -&gt; Test Settings</code> option, but that only seems to allow deployment by specifying absolute paths (which will actually be resolved on the target machines). Is there a way to specify a relative path there, pointing to our ConnectionStrings.config files checked in on TFS? Maybe yet another alternative exists that I'm missing, perhaps using multiple build configurations?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload