el flujo de especificaciones falla al intentar generar el informe de ejecución de prueba

Question

Tengo un proyecto que usa SpecFlow, NUnit y Coypu para realizar pruebas de aceptación en una aplicación web. Tengo el proyecto en buen estado a través de Jenkins en un servidor de compilación. Jenkins llama a un script de psake que ejecuta msbuild en el proyecto de especificaciones, luego el script llama a nunit-console para ejecutar las especificaciones/pruebas, y luego quiero generar un informe de SpecFlow.

Framework "4.0" 

task Default -depends RunSpecs 

task BuildSpecs { 
    $env:EnableNuGetPackageRestore = "true" 
    msbuild /t:Rebuild ReturnsPortal.Specs.csproj 
} 

task RunSpecs -depends BuildSpecs { 
    exec { & "C:\path\to\NUnit 2.5.9\bin\net-2.0\nunit-console-x86.exe" /labels /out=TestResult.txt /xml=TestResult.xml .\bin\Debug\TheWebApp.Specs.dll } 
    exec { & "C:\path\to\SpecFlow\1.8.1\specflow.exe" nunitexecutionreport TheWebApp.Specs.csproj /out:SpecResult.html } 
} 

Esa última llamada exec para specflow.exe falla sin embargo, con:

El elemento < ParameterGroup> debajo elemento < UsingTask> es reconocido. C: \ Archivos de programa (x86) \ Jenkins \ empleos \ \ TheWebApp espacio de trabajo \ web \ Sites \ TheWebApp.nuget \ nuget.targets

Un poco de google indicios de que tal vez es un problema con la versión msbuild siendo utilizado (por ejemplo, here, here). Pero tengo Framework "4.0" en mi secuencia de comandos psake, y el proyecto Specs apunta a .NET Framework 4.0, y se desarrolla bien en el paso de compilación, por lo que no estoy seguro de por qué parece que specflow está utilizando una versión anterior de msbuild. ¿O tal vez es el problema en otro lugar?

Answer 1

Esta fue la respuesta para mí, desde el SpecFlow Wiki:

importante para .NET 4.0 proyectos: Debido specflow.exe se compila para .NET 3.5, no puede cargar .NET 4.0 ensamblados por defecto. Para generar este informe para proyectos .NET 4.0, debe forzar a specflow.exe a usar el tiempo de ejecución de .NET 4.0 utilizando el archivo de configuración. Simplemente copie la configuración a continuación y cree un archivo specflow.exe.config y póngalo junto a su specflow.exe y podrá crear el informe de definición de paso.

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <startup> 
     <supportedRuntime version="v4.0.30319" /> 
    </startup> 
</configuration> 

Answer 2

me trató de utilizar el archivo de configuración solución sugerida anteriormente. Funcionó para realizar pruebas localmente, pero tan pronto como envié mi código a nuestro entorno de CI, se bloqueó porque el entorno de CI no tiene ese archivo de configuración. Restringimos el entorno de CI para que solo use versiones limpias de varios paquetes, por lo que no queríamos intentar inyectar la configuración especial en el servidor de CI.

Notamos que SpecFlow funciona bien con varios de nuestros proyectos .NET 4.0 sin el archivo de configuración especial. Después de investigar un poco, el 'problema' real parece ser NuGet 2.1. Todo funciona bien para proyectos .NET 4.0 con NuGet 1.7.

En algún lugar entre 1.7 y 2.1 NuGet introdujo nuevas características en el archivo NuGet.targets que no son compatibles con las versiones anteriores de MSBuild. Específicamente, el problema parece ser <ParameterGroup> debajo del elemento <UsingTask>, como se explica en el mensaje de error.

Un vistazo rápido al archivo de objetivos indica que la sección es responsable de mantener actualizado NuGet. Al eliminar esta sección, se resuelve completamente el problema de la misma manera que si se agrega el archivo de configuración anterior, aunque también se elimina la funcionalidad de autoactualización que parece proporcionar. Dado que el archivo .targets está comprometido con el repositorio, esta solución también funciona en nuestro entorno de CI sin ningún cambio en el lado de CI.

No es necesariamente una solución mejor que la de ngm, es solo una diferente. Dependiendo de su entorno, esta puede ser una forma preferible de ir, o tal vez no.