¿Cómo controlar la velocidad de ejecución de la prueba en watir-webdriver con el método Watir :: Browser # speed =?

¿Hay alguna manera de controlar la velocidad de ejecución de prueba en watir? ¿Cómo puedo reducir la velocidad de ejecución de la prueba?

Alguien me sugirió usar el siguiente método browser.speed = :slow , pero no existe un método similar para la clase Watir :: Browser con el controlador del navegador que estoy usando actualmente.

La velocidad por defecto es lenta

De acuerdo con la documentación, Watir :: Browser # speed = por defecto es :slow . Sin embargo, por lo que sé, cambiar esta opción solo es válido para Internet Explorer y no tiene efecto en otros navegadores. De hecho, con Chrome o Firefox, el constructor no aceptará un argumento de velocidad y no proporciona una interfaz pública para la opción.

Sin embargo, como con la mayoría de las cosas de Ruby, siempre puedes acceder directamente a las variables y modificarlas. Esto puede o no funcionar para su caso de uso, pero ciertamente podría hacer algo como esto:

 browser = Watir::Browser.new :chrome #=> # browser.instance_variable_set :@speed, :slow #=> :slow browser.instance_variable_get :@speed #=> :slow 

Otras alternativas

En la práctica, las pruebas de los navegadores a menudo implican muchos eventos de JavaScript asíncronos, por lo que es probable que desee esperar a los eventos o elementos en lugar de intentar frenar la prueba en sí. Para hacer eso, puedes usar esperas explícitas o implícitas.

Esperas implícitas

Puede agregar una espera implícita en segundos. Por ejemplo, para esperar hasta 30 segundos para cada evento o elemento:

 browser.driver.manage.timeouts.implicit_wait = 30 

Esperas explícitas

Watir admite tanto Watir :: Wait # hasta y Watir :: Wait # while . Por ejemplo, esperar hasta que un campo de inicio de sesión sea visible:

 Watir::Wait.until { browser.text_field(name: 'login').visible? } 

Usar dormir

Bajo el capó, Watir es Ruby, por lo que también puedes poner el sueño explícito en tus pruebas con Kernel # sleep . El principal inconveniente de hacer esto es que no responde. Su código se suspenderá durante el período de tiempo definido, incluso si el evento o elemento que está esperando se dispara o cambia antes. Esto puede hacer que tus pruebas sean innecesariamente lentas.