Preguntas más frecuentes sobre Live Unit Testing

Live Unit Testing funciona con los tres marcos de pruebas unitarias conocidos que se enumeran en la tabla siguiente. La versión mínima admitida de sus adaptadores y marcos también aparece en la tabla. Los marcos de pruebas unitarias están disponibles en NuGet.org.

Si tiene proyectos de prueba basados en versiones anteriores de MSTest que hacen referencia a Microsoft.VisualStudio.QualityTools.UnitTestFramework y no quiere usar los paquetes de MSTest NuGet más recientes, actualice a Visual Studio 2019 o Visual Studio 2017.

Sí. Live Unit Testing funciona con .NET Core y .NET Framework.

La ventana de salida (cuando se selecciona la lista desplegable Live Unit Testing) debe indicar por qué Live Unit Testing no funciona. Live Unit Testing puede que no funcione por uno de los siguientes motivos:

• Si no se han restaurado los paquetes NuGet a los que los proyectos hacen referencia en la solución, Live Unit Testing no funcionará. Este problema debería resolverse realizando una compilación explícita de la solución o restaurando los paquetes NuGet de la solución antes de activar Live Unit Testing.

• Si en los proyectos usa pruebas basadas en MSTest, asegúrese de quitar la referencia a Microsoft.VisualStudio.QualityTools.UnitTestFramework y agregar referencias a los paquetes NuGet de MSTest más recientes, MSTest.TestAdapter (se requiere la versión 1.1.11 como mínimo) y MSTest.TestFramework (se requiere la versión 1.1.11 como mínimo). Para obtener más información, vea la sección "Marcos de prueba admitidos" del artículo Live Unit Testing con Visual Studio.

• Al menos un proyecto de la solución debe tener una referencia a NuGet o una referencia directa al marco de prueba xUnit, NUnit o MSTest. Este proyecto también debe hacer referencia a un paquete NuGet del adaptador de prueba de Visual Studio correspondiente.

Los errores de compilación se notifican a la ventana Salida cuando se selecciona la lista desplegable Live Unit Testing. Hay algunos problemas comunes causados por una configuración incorrecta en el asistente para configuración que pueden causar problemas de compilación en Live Unit Testing.

• Si la propiedad Raíz del área de trabajo es demasiado larga, es posible que se produzca un error en la compilación debido a excepciones que indican que la ruta de acceso es demasiado larga.

• Si la propiedad Raíz del repositorio no apunta hacia la raíz del repositorio, el área de trabajo se rellenará con el conjunto incorrecto de archivos.

• En el caso de los repositorios git, la propiedad Excluir archivos normalmente evita copiar los archivos especificados en el archivo de gitignore. Sin embargo, es posible proteger los archivos en el repositorio git que se omiten o es posible ejecutar herramientas que generan archivos automáticamente, pero no se generan durante la compilación. En estos casos, se debe elegir la opción "<Custom>" y se debe elegir un conjunto personalizado de reglas que solo muestren las carpetas de artefactos.

Además de los problemas descritos anteriormente, las siguientes configuraciones de proyecto que podrían no compilarse correctamente.

• Si las dependencias del proyecto se especifican como una configuración de solución global y no como ProjectReferences para cada proyecto, Live Unit Testing podría acabar creando el conjunto incorrecto de proyectos. Para corregir esto, agregue referencias explícitas entre proyectos.

• Hasta que se elija una lista de reproducción de Live Unit Testing, Live Unit Testing no compilará ningún proyecto. Para corregir esto, incluya algunas pruebas en la lista de reproducción de Live Unit Testing.

• Si en los proyectos usa pruebas basadas en MSTest, asegúrese de quitar la referencia a Microsoft.VisualStudio.QualityTools.UnitTestFramework y agregar referencias a los paquetes NuGet de MSTest más recientes, MSTest.TestAdapter (se requiere la versión 1.1.11 como mínimo) y MSTest.TestFramework (se requiere la versión 1.1.11 como mínimo). Para más información, consulte Marcos de prueba admitidos.

• Al menos un proyecto de la solución debe tener una referencia a NuGet o una referencia directa al marco de prueba xUnit, NUnit o MSTest. Este proyecto también debe hacer referencia a un paquete NuGet del adaptador de prueba de Visual Studio correspondiente. También se puede hacer referencia al adaptador de prueba de Visual Studio a través de un archivo .runsettings. El archivo .runsettings debe tener una entrada como la del ejemplo siguiente:

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

• Un problema común es que no todos los archivos se copian en la carpeta de prueba. Es posible que tenga que agregar algunos elementos de Dependencia de prueba de Live Unit Testing a los archivos csproj.

• Otra incidencia es el tiempo de espera. Dado que Live Unit Testing ejecuta pruebas indefinidamente, anula automáticamente una ejecución si las pruebas se ejecutan durante demasiado tiempo. Puede aumentar el tiempo de espera en el Asistente para del proyecto.

• Si varios proyectos de la solución hacen referencia al paquete del adaptador de prueba de NuGet, todos ellos deben actualizarse a la versión admitida.

• Asegúrese de que el archivo .props de MSBuild importado del paquete del adaptador de prueba también se actualiza correctamente. Compruebe la versión/ruta de la importación del paquete NuGet, que normalmente se encuentra en la parte superior del archivo del proyecto, como la siguiente:

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Si la solución requiere la compilación de pasos personalizados para la instrumentación (Live Unit Testing) que no son necesarios para la compilación no instrumentada "normal", entonces puede agregar código al proyecto o a los archivos .targets que compruebe la propiedad BuildingForLiveUnitTesting y realice pasos personalizados anteriores y posteriores a la compilación. También puede optar por quitar ciertos pasos de compilación (como la publicación o generación de paquetes) o por agregar dichos pasos (por ejemplo, copiar requisitos previos) a una compilación de Live Unit Testing basada en esta propiedad de proyecto. Si personaliza la compilación en función de esta propiedad, no se altera la compilación normal de ninguna forma y solo afecta a las compilaciones de Live Unit Testing.

Por ejemplo, puede haber un destino que genere paquetes NuGet durante una compilación normal. Probablemente no desee que los paquetes NuGet se generen después de cada edición que realice. Por tanto, puede deshabilitar ese destino en la compilación de Live Unit Testing haciendo algo parecido a lo siguiente:

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' != 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

Hay varias diferencias:

• La ejecución o depuración de pruebas desde la ventana Explorador de pruebas ejecuta binarios normales, mientras que Live Unit Testing ejecuta binarios instrumentados. Si desea depurar binarios instrumentados, la incorporación de una llamada de método Debugger.Launch al método de prueba hace que el depurador se inicie siempre que se ejecute el método (incluso cuando lo ejecuta Live Unit Testing); después, puede asociar y depurar el binario instrumentado. Sin embargo, nuestro deseo es que la instrumentación sea transparente para el usuario en la mayoría de los escenarios y que no tenga que depurar binarios instrumentados.

• Live Unit Testing no crea un dominio de aplicación para ejecutar pruebas, sino que estas se ejecutan desde la ventana Explorador de pruebas para crear un dominio de aplicación.

• Live Unit Testing ejecuta pruebas secuencialmente en cada ensamblado de prueba. En el Explorador de pruebas, puede optar por ejecutar varias pruebas en paralelo.

• De forma predeterminada, el Explorador de pruebas ejecuta pruebas en un contenedor uniproceso (STA), mientras que Live Unit Testing ejecuta pruebas en un contenedor multiproceso (MTA). Para ejecutar pruebas de MSTest en STA en Live Unit Testing, decore el método de prueba o la clase contenedora con el atributo <STATestMethod> o <STATestClass> que puede encontrarse en el paquete NuGet MSTest.STAExtensions 1.0.3-beta. Para NUnit y xUnit, decore el método de prueba con el atributo <RequiresThread(ApartmentState.STA)> y <STAFact>, respectivamente.

Vea la sección "Incluir y excluir proyectos de prueba y métodos de prueba" del artículo Live Unit Testing con Visual Studio para obtener la configuración específica del usuario. La inclusión o exclusión de pruebas es útil cuando se quiere ejecutar un conjunto específico de pruebas para una sesión de edición determinada o para conservar sus propias preferencias personales.

Para la configuración específica de la solución, puede aplicar el atributo System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute mediante programación para excluir los métodos, las propiedades, las clases o las estructuras de la instrumentación que realiza Live Unit Testing. Además, también puede establecer la propiedad <ExcludeFromCodeCoverage> en true en el archivo de proyecto para excluir todo el proyecto de la instrumentación. Live Unit Testing seguirá ejecutando las pruebas que no se han instrumentado, pero su cobertura no se visualizará.

También puede comprobar si Microsoft.CodeAnalysis.LiveUnitTesting.Runtime se carga en el dominio de aplicación actual y deshabilitar pruebas en base a ello. Por ejemplo, puede hacer algo como lo siguiente con xUnit:

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

La solución se puede compilar incluso si no realiza ninguna edición si el proceso de compilación genera código fuente que forma parte de la propia solución y los archivos de destino de compilación no tienen entradas y salidas adecuadas especificadas. Los destinos deben disponer de una lista de entradas y salidas para que MSBuild pueda realizar las comprobaciones actualizadas adecuadas y determinar si es necesaria una nueva compilación.

Live Unit Testing inicia una compilación siempre que detecta que los archivos de origen han cambiado. Dado que la compilación de la solución genera archivos de origen, Live Unit Testing entra en un bucle de compilación infinito. Pero si las entradas y salidas del destino se comprueban cuando Live Unit Testing inicia la segunda compilación (después de detectar los archivos de origen recién generados desde la compilación anterior), sale del bucle de compilación porque las comprobaciones de las entradas y salidas indican que todo está actualizado.

Es posible que no vea los iconos del editor si, por alguna razón, los ensamblados en los que está trabajando Live Unit Testing no están instrumentados. Por ejemplo, Live Unit Testing no es compatible con proyectos que establecen <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. En este caso, el proceso de compilación necesita actualizarse para quitar esta configuración o cambiarla a true para que Live Unit Testing funcione. 

Puede hacer varias cosas para recopilar registros más detallados:

• Vaya a Herramientas>Opciones>Live Unit Testing y cambie la opción de registro a Detallado. El registro detallado hace que se muestren registros más detallados en la ventana de salida.

• Establezca la variable de entorno de usuario LiveUnitTesting_BuildLog en el nombre del archivo que desea utilizar para capturar el registro de MSBuild. A continuación, a partir de ese archivo, se pueden recuperar los mensajes de registro de MSBuild detallados procedentes de las compilaciones de Live Unit Testing.

• Establezca la variable de entorno de usuario LiveUnitTesting_TestPlatformLog en 1 para capturar el registro de la plataforma de prueba. A continuación, a partir de [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID], se pueden recuperar los mensajes de registro detallados de la plataforma de prueba procedentes de las ejecuciones de Live Unit Testing.

• Cree una variable de entorno de usuario denominada VS_UTE_DIAGNOSTICS y establézcala en 1 (o en cualquier valor) y reinicie Visual Studio. Ahora debería ver una gran cantidad de información de registro en la pestaña Salida - Pruebas en Visual Studio.

No, no debe abrir ni editar los archivos en los directorios de compilación y prueba de la carpeta del área de trabajo. Live Unit Testing debe administrar todos los archivos de la carpeta src, para mantenerlos sincronizados entre el Raíz del repositorio y Raíz del área de trabajo.

Sí, pero debe asegurarse de que está habilitado. Si usa una unidad de desarrollo, asegúrese de que el filtro del sistema de archivos proyectado (ProjFS) esté habilitado. Por ejemplo, el siguiente comando habilita ProjFS y Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt, WdFilter

Vea también

• Live Unit Testing