unit testing - Las pruebas de Watin fallan en CC.Net

unit-testing xunit.net

Question

Estoy ejecutando pruebas de Watin con xUnit en CC.Net bajo Windows Server 2003.

Tengo muchas pruebas que funcionan bien en las cajas de desarrollo con TestDriven.Net y en el servidor con la aplicación xUnit gui. Sin embargo, cuando CC.Net ejecuta las pruebas (como parte de una tarea MSBuild) la función

ie.ContainsText("some text to find");

nunca devuelve el valor esperado. Otras funciones y propiedades en el objeto IE parecen funcionar bien: Botón (...). Click (), TextBox (...). Valor, etc.

Soy consciente de que la cuenta del servicio necesita "Permitir que el servicio interactúe con el escritorio".

He intentado ejecutar este servicio CC bajo el sistema local y el administrador local. La cuenta de administrador simplemente se cuelga y nunca parece terminar de ejecutar las pruebas (aunque sí crea una instancia del proceso iexplorer.exe).

¿Es esto un problema con la autorización en el servidor, o he dejado algo fuera de la configuración?

Answer 1

He recibido un par de sugerencias fuera de línea:

1. Intente ejecutar las pruebas con msbuild en el servidor.
2. Intente iniciar CC.Net desde la consola en lugar de hacerlo como servicio.

Editará con resultados.

EDITAR:

Resultados:

1. Soy completamente capaz de ejecutar las pruebas con msbuild en el servidor.
2. Cuando ejecuto ccnet.exe desde la línea de comandos, las pruebas funcionan bien. Sin embargo, cuando configuro una tarea para iniciar ccnet.exe desde la línea de comando al inicio, las pruebas se cuelgan y nunca terminan (eventualmente se agota el tiempo de espera).

La solución parcial es ejecutar el ejecutable de línea de comando en una sesión que nunca muere. Realmente no me gusta esta solución, por lo que cualquier contribución adicional sería apreciada.

Answer 2

Acabamos de terminar de descubrir cómo solucionar este problema. Ahora tenemos pruebas de watin que se ejecutan a través de CruiseControl.net ejecutándose como un servicio.

Necesitamos que nuestro servicio cc.net se ejecute como un usuario específico para acceder al sitio web que estamos probando debido a la forma en que se configura la seguridad. Como el servicio se ejecuta como un usuario de dominio, la casilla ''Permitir que el usuario interactúe con el escritorio'' está deshabilitada en la pestaña de seguridad del servicio. No queremos simplemente ejecutar el proceso de comando de un usuario que siempre ha iniciado sesión porque queremos que el proceso se inicie automáticamente al reiniciar. Ahora nos hemos dado cuenta

La forma en que trabajamos con esto fue creando primero un archivo por lotes para llamar a nunit-console.exe. Los parámetros de nunit-console.exe se pasan al archivo por lotes como parámetros que luego pasan los parámetros. La segunda y última línea del archivo de proceso por lotes devuelve el código de retorno devuelto por nunit-console.exe. El archivo por lotes esencialmente tiene este aspecto:

 nunit-console.exe %1 %2
exit /b %ERRORLEVEL%

La cantidad de parámetros que pasa a nunit-console puede ser diferente en función de sus necesidades.

Estamos usando nant para nuestras construcciones, entonces reemplazamos nuestra tarea nant existente para llamar a nunit-console con una tarea ejecutiva que llama a cmd.exe que se ve así:

 <exec program="cmd.exe" failonerror="true">
<arg value="/interactive" />
<arg value="/c" />
<arg value="[batch file name]" />
<arg value="[parameter one value]" />
<arg value="[parameter two value" />
</exec>

No sé cómo sería la misma tarea en msbuild pero estoy seguro de que puedes buscarla. El resultado final es esencialmente un comando que se ve así:

 cmd.exe /interactive /c [batch file name] [parameter one value] [parameter two value]

Alternativamente, puede usar nant y simplemente crear tareas de msbuld nant para llamar a sus compilaciones existentes.

El parámetro ''/ interactive'' para cmd.exe es la clave, ejecuta el archivo por lotes en un proceso que tiene permiso para interactuar con el escritorio. En realidad, no estoy seguro si se requiere el parámetro ''/ c'', pero está funcionando como está. Todavía estamos pidiendo a nunit que registre los resultados en el mismo archivo xml, por lo que nuestra tarea de fusión no tuvo que cambiar y el informe de los resultados de la prueba al control de crucero funciona muy bien.

Answer 3

Watin confía en la automatización del navegador para hacer su trabajo, por lo tanto, el ajuste "permitir que el servicio interactúe con el escritorio".

Cuando Watin intente funcionar, lo hará bajo la cuenta de servicio, no en el escritorio que está actualmente conectado, y dado que va a funcionar, es posible que la cuenta con la que está ejecutando Watin no haya iniciado IE antes y podría estar sentado en la secuencia de inicio inicial para IE, donde solicita configuración y todo eso, hoo-hah.

Además, si recuerdo correctamente, la interacción con la configuración de escritorio requiere un inicio de sesión activo para interactuar. Si nadie está conectado en ese momento, no habrá nada para que el servicio pueda hablar y no creará un nuevo escritorio para usted.

Answer 4

No estoy seguro de por qué esa respuesta fue marcada como correcta con un ejemplo de exec no válido.

Lo reescribí para:

<exec> <baseDirectory>WatinTestDir</baseDirectory> <executable>cmd.exe</executable> <buildArgs>/interactive /C nunit-launcher.bat Test.dll /xml:../Test-results.xml</buildArgs> <buildTimeoutSeconds>2400</buildTimeoutSeconds> </exec>

Lo cual funciona ... pero falla de todos modos ...

Answer 5

Esta es una buena solución, pero no resuelve el problema. Está tratando de descargar archivos usando Watin.

http://blog.kikicode.com/2011/10/run-minimized-batch-file-in-task.html

Esto funcionó para mí. El problema era que el comando cmd estaba bloqueando IE. Cuando pude minimizar el mensaje de cmd, permitió que IE se enfocara y descargara los archivos que necesitaba en mi proceso.

Answer 6

Seguí este ejemplo, pero no me ayudó, por desgracia. Como esta pregunta es sobre nant, y uso msbuild, abrí una pregunta separada para esto aquí .