Прямо сейчас мои кодированные тесты пользовательского интерфейса используют их app.config для определения домена, в котором они выполняются, который имеет отношение 1-1 к среде. Чтобы упростить это:

www.test.comwww.UAT.comwww.prod.com

и в App.config у меня есть что-то вроде:

<configuration>
    <appSettings>
        <add key="EnvironmentURLMod" value ="test"/>

и чтобы запустить тест в другой среде, я вручную изменяю значение между прогонами. Например, я открываю браузер так:

browserWindow.NavigateToUrl(new Uri("http://www."
                + ConfigurationManager.AppSettings.Get("EnvironmentURLMod")
                + ".com"));

Очевидно, это не элегантно. Я предполагаю, что у меня было видение, где мы добавляем новый app.config для каждого запуска, но в качестве спойлера этот тест будет выполняться в ~ 10 средах, а не в 3, и какие среды он может запустить, может измениться.

Я знаю, что могу отделить эти модификации URL среды от еще одного XML-файла и сделать так, чтобы тесты обращались к ним последовательно вуправляемый данными сценарий, Но даже кажется, что это не совсем то, что мне нужно, так как если одна среда не сработает, весь тест рухнет. я виделПеременные среды в качестве предложения, но это потребует создания агента тестирования для каждой среды, изменения их реестров и запуска тестов для каждой из них. Если это то, что нужно, то конечно, но кажется, что огромная полоса пропускания виртуальной машины будет использоваться для набора строк.

В идеальном мире я хотел бы связать эти моды для URL с чем-то вроде настроек теста, сред MTM или сборок. Я хочу выполнить набор тестов для каждого домена и сообщать отдельно.

Короче говоря, каков наилучший способ параметризации этих тестов? Есть ли способ, который не предполагает очереди новых сборок или сброса конфигурационных файлов? Является ли Data Driven Testing ответом? Я правильно структурировал свое решение? Кажется, что это должен быть такой распространенный сценарий, но мой поиск в Google не совсем меня туда привел.

Любая помощь приветствуется.