c# - unitarias - Cómo acceder a TestRunParameters dentro del archivo RunSettings

pruebas automatizadas visual studio 2017

Question

Al leer https://msdn.microsoft.com/en-us/library/jj635153.aspx , he creado un archivo .RunSettings con algunos parámetros similares al ejemplo:

  <TestRunParameters>
    <Parameter name="webAppUrl" value="http://localhost" />
    <Parameter name="webAppUserName" value="Admin" />
    <Parameter name="webAppPassword" value="Password" />
  </TestRunParameters>

Planeo tener un archivo .RunSettings para cada uno de nuestros entornos con las URL y las credenciales adecuadas para ejecutar una prueba CodedUI en el entorno del archivo RunSettings especificado.

Puedo ver que desde la línea de comandos para hacer referencia al archivo de configuración que puedo ejecutar:

vstest.console myTestDll.dll /Settings:Local.RunSettings /Logger:trx
vstest.console myTestDll.dll /Settings:QA.RunSettings /Logger:trx

etc ...

Pero no veo ninguna manera que TestRunParameters cómo utilizar realmente los TestRunParameters desde la prueba de IU codificada.

Lo que me gustaría hacer es configurar los inicializadores de prueba que usan los TestRunParameters para determinar dónde iniciar sesión y qué credenciales usar. Algo como esto:

[TestInitialize()]
public void MyTestInitialize()
{

    // I''m unsure how to grab the RunSettings.TestRunParameters below
    string entryUrl = ""; // TestRunParameters.webAppUrl
    string userName = ""; // TestRunParameters.webAppUserName
    string password = ""; // TestRunParameters.webAppPassword

    LoginToPage(entryUrl, userName, password);
}

public void LoginToPage(string entryUrl, string userName, string password)
{
    // Implementation
}

¡La información sobre cómo hacer referencia a los TestRunParameters es muy apreciada!

EDITAR

/// <summary>
/// Summary description for CodedUITest1
/// </summary>
[CodedUITest]
public class CodedUITest1
{

    public static string UserName = string.Empty;

    [ClassInitialize]
    public static void TestClassInitialize(TestContext context)
    {
        UserName = context.Properties["webAppUserName"].ToString();
        Console.WriteLine(UserName);
    }

    [TestMethod]
    public void CodedUITestMethod1()
    {
        this.UIMap.RecordedMethod1();
        // To generate code for this test, select "Generate Code for Coded UI Test" from the shortcut menu and select one of the menu items.
    }

    // Rest of the default class - TestContext instantiation, UI map instantiation, etc
}

La excepción que estoy recibiendo al correr:

Excepcion de referencia nula

@williamfalconeruk He actualizado mi clase de prueba como la de arriba, pero sigo teniendo el mismo error, ¿alguna idea de lo que estoy haciendo mal?

Answer 1

¿Por qué no usas la configuración de la aplicación?

A continuación, puede leerlos en cualquier lugar como

var yesICan= Properties.Settings.Default.IToldYou;

Puedes crear propiedades a partir de ellas, puedes hacer muchas cosas.

public string URL_WEBOFFICE
    {
        get
        {
            return Properties.Settings.Default.WEBOFFICE_URL.Replace("***", Properties.Settings.Default.SiteName);
        }

    }

Answer 2

Esto funciona para mí (VS2017-pro):

namespace TestApp.Test
{
    [TestClass]
    public class UnitTest1
    {
        // This enables the runner to set the TestContext. It gets updated for each test.
        public TestContext TestContext { get; set; }
        [TestMethod]
        public void TestMethod1()
        {
            // Arrange
            String expectedName = "TestMethod1";
            String expectedUrl = "http://localhost";

            // Act
            String actualName = TestContext.TestName;
            // The properties are read from the .runsettings file
            String actualUrl = TestContext.Properties["webAppUrl"].ToString();

            // Assert
            Assert.AreEqual(expectedName, actualName);
            Assert.AreEqual(expectedUrl, actualUrl);
        }

        [TestMethod]
        public void TestMethod2()
        {
            // Arrange
            String expectedName = "TestMethod2";

            // Act
            String actualName = TestContext.TestName;

            // Assert
            Assert.AreEqual(expectedName, actualName);
        }
    }
}

Asegúrese de seleccionar el archivo de configuración que desea usar, aquí: Prueba -> Configuración de prueba.

Answer 3

Para aquellos que usan Resharper con este problema, descubrí la solución (no es necesario deshabilitar Resharper):

1. Vaya al menú superior de Visual Studio -> Resharper -> Opciones

2. Busque la sección Herramientas, expanda "Prueba de unidad"

3. Haga clic en "MsTest". La casilla de verificación debe estar activada, pero la ruta del archivo de configuración de prueba a continuación puede estar en blanco. Si es así, haga clic en Examinar y seleccione el archivo de ajustes que desea usar.

4. Haga clic en guardar, reconstruir e intente ejecutar las pruebas, los parámetros ahora deberían funcionar.

No estoy seguro de por qué, pero simplemente seleccionando el archivo de configuración de prueba en el menú Pruebas -> La configuración de prueba no funciona realmente cuando se usa Resharper, por lo que este archivo debe apuntarse explícitamente directamente en las opciones de Resharper.

Answer 4

Pude resolver esto para pruebas de unidad al deshabilitar Resharper. Ojalá pudiera decir lo mismo para las pruebas de IU codificadas.

Answer 5

También me di cuenta de esto recientemente, ya que queríamos alejarnos del uso de variables del entorno heredado. La solución provista a continuación fue adecuada para nuestras necesidades, pero puede haber una mejor ...

Resulta que puede acceder a estos en el TestContext de un método ClassInitialize de su dispositivo de prueba. Hay un diccionario de Properties que tiene estos parámetros, y puede acceder a los valores aquí:

[ClassInitialize]
public static void TestClassinitialize(TestContext context)
{
    var webAppUrl = context.Properties["webAppUrl"].ToString();

   //other settings etc..then use your test settings parameters here...
}

Nota : estos son estáticos, por lo que si necesita acceder a este puede que necesite configurar propiedades estáticas para acceder dentro de su código de prueba.

Una alternativa sugerida es utilizar un enfoque de prueba impulsada por datos. Aquí hay información básica sobre pruebas basadas en datos que también pueden ayudar: https://msdn.microsoft.com/en-us/library/ms182527.aspx

Como dije, la solución anterior se adaptó a nuestras necesidades en un nivel básico.

ACTUALIZACIÓN: vea la imagen a continuación en respuesta a la configuración de prueba que devuelve nulo ...

Answer 6

Una alternativa para desactivar Resharper es habilitar el soporte de MSTest y seleccionar el archivo de configuración de prueba en el cuadro de diálogo Opciones de Resharper (-> Herramientas -> Prueba de unidad -> MsTest).

Answer 7

Yo también estaba tratando de hacer esto exactamente. Como muchos de ustedes saben, la ejecución de pruebas a través de MTM expone algunas propiedades adicionales al TestContext, incluido el nombre de la configuración de ejecución utilizada. Utilicé esta propiedad como una "clave foránea" para nuestros datos de prueba, lo que nos permite especificar las direcciones URL del entorno, etc. sin tener que codificarlos o usar las herramientas increíblemente deslustradas de "Conducción de datos" que vienen con las pruebas listas para usar.

Por supuesto, no hay forma de exponer las propiedades de tiempo de ejecución al ejecutar pruebas como parte de un flujo de trabajo de liberación o BDT, además de lo que @kritner está intentando, lo que Microsoft describe HERE . Sin embargo, si lee los comentarios de ese enlace, descubrirá lo que puede inferir aquí:

• Necesita usar VS 2013 R5 o VS 2015 para usar esta solución
• ¡ Solo funcionará para pruebas unitarias!

Aquellos de nosotros que intentamos ejecutar UI o cargar pruebas como parte de un flujo de trabajo de CI o CD estamos completamente atornillados. No obtiene ninguna propiedad adicional en testContext, incluso cuando ejecuta un Plan / Suite con ciertas configuraciones de prueba (no configuraciones) creadas en MTM. Es posible que @Adam haya podido hacer que esto funcione cuando se ejecuta frente a la depuración, pero eso puede haber funcionado solo con pruebas de unidad. A través de CodedUI no he podido recuperar las propiedades sin obtener una NullReferenceException. Aquí hay un ejemplo del código janky que estaba usando para investigar:

if (testContextInstance.Properties["__Tfs_TestConfigurationName__"] != null) //Exposed when run through MTM
{
TFSTestConfigurationName = testContextInstance.Properties["__Tfs_TestConfigurationName__"].ToString();
}
else TFSTestConfigurationName = "Local"; //Local
var configName = testContextInstance.Properties["configurationName"] ?? "No Config Found";
Trace.WriteLine("Property: " + configName);

Y el XML de mi archivo .runsettings:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- Parameters used by tests at runtime. These are required as a substitute for TFS/MTM test settings.-->
  <!-- File instructions: https://msdn.microsoft.com/en-us/library/jj635153.aspx#example -->
  <!-- TFS instructions: https://blogs.msdn.microsoft.com/visualstudioalm/2015/09/04/supplying-run-time-parameters-to-tests/ -->  
  <TestRunParameters>
    <Parameter name="configurationName" value="Local" />
  </TestRunParameters>
</RunSettings>

Y un extracto de .trx producido por el flujo de trabajo de la BDT:

Property: No Config Found 

Answer 8

Para el problema NullReferenceException:

También enfrenté el mismo problema recientemente y la solución es tener la última actualización de Visual Studio 2013 . En este momento, la última actualización es la Actualización 5. No estoy seguro de qué actualización en particular soluciona este problema. Apliqué la Actualización 5 y pude acceder con éxito a TestRunParameters en el método ClassInitialize.

Puede encontrar las actualizaciones @ https://support.microsoft.com/en-us/kb/2829760 Así que tuve dos máquinas, en una todo funcionaba bien y en la otra estaba obteniendo la excepción. Investigué que la única diferencia es la Actualización de VS; Se aplicó y eso solucionó el problema. :)