Aquí podría ser tu PUBLICIDAD


Las pruebas de Watin fallan en CC.Net

votos
4

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?

Publicado el 12/03/2009 a las 21:09
fuente por usuario Joel
En otros idiomas...        العربية       

6 respuestas

votos
10

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 compilaciones, 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.

Respondida el 06/08/2009 a las 09:43
fuente por usuario Brett


Aquí podría ser tu PUBLICIDAD


votos
1

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 girar IE, 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.

Respondida el 06/08/2009 a las 07:06
fuente por usuario Richard Banks

votos
0

Esta es una buena solución, pero no resuelve el problema es que está intentando descargar archivos utilizando Watin.

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

Esto funcionó para mí. El problema fue que la pronta cmd estaba bloqueando IE de venir. Cuando yo era capaz de minimizar el cmd permitió IE para obtener el foco y descarga los archivos que necesitaba en mi proceso.

Respondida el 07/05/2014 a las 03:48
fuente por usuario workingobrien

votos
0

He seguido este ejemplo, pero no me ayudaron, por desgracia. Dado que esta pregunta se refiere a Nant, y lo uso msbuild, he abierto una pregunta separada para este en aquí .

Respondida el 29/10/2013 a las 09:21
fuente por usuario Chameera Dedduwage

votos
0

No sé por qué la respuesta correcta fue marcado con un ejemplo ejecutivo no válida ..

Reescribí a:

<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>

Que se extiende .. pero falla todo lo mismo ..

Respondida el 07/01/2011 a las 01:10
fuente por usuario Brunis

votos
0

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.

Respondida el 13/03/2009 a las 09:08
fuente por usuario Joel