How to set up a hierarchical structure of .runsettings files in a solution

Marcel Müller 21 Reputation points
2021-02-05T13:13:32.517+00:00

I have a solution containing several NUnit test projects. Each test project has its own runsettings file, that I use to parameterize the test of the corresponding test project. This is seen below:

64536-anmerkung-2021-02-05-135028.png

I am retrieving the TestRunParameters using following code:

var hostName = TestContext.Parameters["hostname"];

Now it turned out, that some test projects use the same parameters and it would be senseless to pass the same parameter in multiple runsettings files.
My prefered solution would be to have runsettings file for all test projects and additionally to that a runsettings file for each test project containing specific parameters according to the project. So I could check if a parameter is in the global runsettings file and if it's not to check if its defined in the local runsettings in the corresponding project.

Does this work? Is there another workaround I could get a "hierarchical" behaviour like this?

I am new to MSDN... If I was not specific enough don't hesitate to ask me for details using the comment section

.NET Runtime
.NET Runtime
.NET: Microsoft Technologies based on the .NET software framework.Runtime: An environment required to run apps that aren't compiled to machine language.
1,135 questions
Visual Studio Testing
Visual Studio Testing
Visual Studio: A family of Microsoft suites of integrated development tools for building applications for Windows, the web and mobile devices.Testing: The act or process of applying tests as a means of analysis or diagnosis.
333 questions
0 comments No comments
{count} votes

Accepted answer
  1. Michael Taylor 49,356 Reputation points
    2021-02-05T15:01:00.847+00:00

    I don't believe hierarchical runsettings are supported based upon the documentation here that using a .runsettings file overrides the solution-level version. In theory you could go the environment variable route perhaps but that would be dependent upon what you're changing.

    I think the better route would be to create your own "parameters" data file. In the initialization code of the test (ideally a base class all your test classes derive from) look for this file and, if found, overwrite any parameters in the context with the new values from the file.

    Yet another approach, again depending upon what you're changing, is to have your test run determine which of several settings files to use. This would be most useful if you were simply changing URLs or something between environments.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful