Preguntas más frecuentes sobre Live Unit Testing

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

Si tiene proyectos de prueba basados en MSTest anteriores que hacen referencia a Microsoft.VisualStudio.QualityTools.UnitTestFramework y no desea pasar a los paquetes NuGet de MSTest 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 Salida (cuando se selecciona la lista desplegable Live Unit Testing) debe indicarle por qué Live Unit Testing no funciona. Live Unit Testing puede no funcionar por uno de los siguientes motivos:

• Si no se han restaurado los paquetes NuGet a los que hacen referencia los proyectos de la solución, Live Unit Testing no funcionará. Realizar una compilación explícita de la solución o restaurar paquetes NuGet en la solución antes de activar Live Unit Testing debe resolver este problema.

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

• Al menos un proyecto de la solución debe tener una referencia de NuGet o una referencia directa al marco de pruebas xUnit, NUnit o MSTest. Este proyecto también debe hacer referencia a un paquete NuGet de adaptadores 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 de que pueden causar problemas de compilación en Live Unit Testing.

• Si el propiedad raíz del área de trabajo es demasiado largo, 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 raíz del repositorio propiedad 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 Exclude files 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 generen 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 terminar creando el conjunto incorrecto de proyectos. Para corregir esto, agregue referencias explícitas entre proyectos.

• Hasta que se elija un 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 Live Unit Testing.

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

• Al menos un proyecto de la solución debe tener una referencia de NuGet o una referencia directa al marco de pruebas xUnit, NUnit o MSTest. Este proyecto también debe hacer referencia a un paquete NuGet de adaptadores 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 de .runsettings. El archivo .runsettings debe tener una entrada como en el ejemplo siguiente:

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

Live Unit Testing no puede compilar los proyectos del generador de origen con instrumentación. Debido a cómo el compilador de C# configura la carga de ensamblados para los generadores de origen, el intento de compilar proyectos de generador de origen con instrumentación no puede cargar ensamblados de Live Unit Testing.

Puede establecer <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> propiedad en los archivos csproj del generador de origen para que estos proyectos se compilen en Live Unit Testing.

Live Unit Testing ejecuta la compilación dentro de su propio proceso por motivos de rendimiento. Si este proceso de compilación independiente está causando un error, puede establecer <UseInProcMSBuildNode>false</UseInProcMSBuildNode> en el archivo .lutconfig para asegurarse de que toda la compilación se produce en el proceso de MSBuild.

• 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 Live Unit Testing Dependency a los archivos de csproj de.

• Otro problema 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, cada uno de ellos debe actualizarse a la versión admitida.

• Asegúrese de que msBuild archivo .props importado desde el paquete del adaptador de prueba también se actualiza correctamente. Compruebe la versión o ruta de acceso del paquete NuGet de la importación, que normalmente se puede encontrar cerca de 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 pasos personalizados para compilar para la instrumentación (Live Unit Testing) que no son necesarios para la compilación no instrumentada "normal", puede agregar código al proyecto o archivos .targets que comprueban la propiedad BuildingForLiveUnitTesting y realiza pasos de compilación previos y posteriores personalizados. También puede quitar determinados pasos de compilación (como publicar o generar paquetes) o agregar pasos de compilación (como copiar requisitos previos) a una compilación de Live Unit Testing basada en esta propiedad de proyecto. La personalización de la compilación basada en esta propiedad no modifica la compilación normal de ninguna manera 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 quiera que se generen paquetes NuGet después de cada edición que realice. Por lo tanto, puede deshabilitar ese destino en la compilación 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:

• Ejecutar o depurar pruebas desde el explorador de pruebas de ventana ejecuta archivos binarios normales, mientras que Live Unit Testing ejecuta archivos binarios instrumentados. Si desea depurar archivos binarios instrumentados, agregar una llamada de método Debugger.Launch en el método de prueba hace que el depurador se inicie cada vez que se ejecute ese método (incluido cuando Live Unit Testing lo ejecuta) y, a continuación, puede adjuntar y depurar el binario instrumentado. Sin embargo, esperamos que la instrumentación sea transparente para la mayoría de los escenarios de usuario y que no sea necesario depurar archivos binarios instrumentados.

• Live Unit Testing no crea un nuevo dominio de aplicación para ejecutar pruebas, pero las pruebas se ejecutan desde la ventana Explorador de pruebas crean un dominio de aplicación.

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

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

Consulte la sección "Incluir y excluir proyectos de prueba y métodos de prueba" de la Usar Live Unit Testing en Visual Studio artículo para la configuración específica del usuario. Incluir o excluir pruebas es útil cuando se quiere ejecutar un conjunto específico de pruebas para una sesión de edición determinada o 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 métodos, propiedades, clases o estructuras de la instrumentación de Live Unit Testing. Además, también puede establecer la propiedad <ExcludeFromCodeCoverage> en true en el archivo de proyecto para excluir que todo el proyecto se instrumente. 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 las pruebas en función de por qué. Por ejemplo, puede hacer algo parecido a 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 puede compilar incluso si no está realizando modificaciones 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 las entradas y salidas adecuadas especificadas. A los destinos se les debe asignar una lista de entradas y salidas para que MSBuild pueda realizar las comprobaciones up-to-date adecuadas y determinar si se requiere una nueva compilación.

Live Unit Testing inicia una compilación cada vez 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. Sin embargo, 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 de la compilación anterior), se interrumpe el bucle de compilación porque las entradas y salidas comprueban que todo está up-to-date.

Es posible que no vea iconos en el editor si los ensamblados en los que Live Unit Testing funciona no se instrumentan por ningún motivo. Por ejemplo, Live Unit Testing no es compatible con proyectos que establecen <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. En este caso, el proceso de compilación debe actualizarse para quitar esta configuración o cambiarla a true para que Live Unit Testing funcione. 

Puede realizar varias acciones para recopilar registros más detallados:

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

• Establezca la variable de entorno de usuario LiveUnitTesting_BuildLog en el nombre del archivo que desea usar para capturar el registro de MSBuild. Los mensajes de registro detallados de MSBuild de las compilaciones de Live Unit Testing se pueden recuperar de ese archivo.

• Establezca la variable de entorno de usuario LiveUnitTesting_TestPlatformLog en 1 para capturar el registro de la plataforma de prueba. Los mensajes detallados del registro de test Platform de las ejecuciones de Live Unit Testing se pueden recuperar de [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID].

• Cree una variable de entorno de nivel de usuario denominada VS_UTE_DIAGNOSTICS y establézcala en 1 (o cualquier valor) y reinicie Visual Studio. Ahora debería ver una gran cantidad de registros 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 de, para mantenerlos sincronizados entre el raíz del repositorio de 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 sistema de archivos proyectado (ProjFS) filtro esté habilitado. Por ejemplo, el siguiente comando habilita ProjFS y Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

Consulte también

• Live Unit Testing