visual studio - tutorial - La prueba de IU codificada es lenta a la espera del subproceso de la IU
visual studio code themes (3)
Agregué Pruebas de UI Codificadas a mi solución ASP.NET MVC en Visual Studio 2013. Me quedé consternado al ver la lentitud con que se ejecutan las pruebas; Cada página se queda ahí por un minuto o más antes de que la maquinaria de prueba se despierte y comience a completar los campos del formulario.
Después de algunos experimentos (incluyendo la desactivación de SmartMatch ), descubrí que simplemente llamar
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;
resuelve el problema Pero, como se esperaba, la prueba falla con frecuencia porque el subproceso de la interfaz de usuario no está listo para que la maquinaria de prueba interactúe con los controles del formulario.
Vocación
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.UIThreadOnly;
hace que la prueba se ejecute de forma fiable, aunque sea lentamente.
¿Alguna idea o sugerencia? ¿Alguna esperanza de que alguien pueda tener alguna idea de la magia incorporada en la maquinaria WaitForReady? ¿Hay otras configuraciones relacionadas con WaitForReady con las que puedo WaitForReadyLevel además de WaitForReadyLevel ?
Después de un poco de experimentación, he desarrollado lo que parece ser una combinación de configuraciones que permiten que mis pruebas de IU codificadas se ejecuten de manera confiable a toda velocidad, más rápido de lo que puedo interactuar con el sitio web a mano.
Nota: La "documentación" relevante (si llama a un blog "documentación") se puede encontrar aquí:
El truco requiere varias modificaciones a la configuración de reproducción predeterminada:
La configuración de
WaitForReadyLevel = WaitForReadyLevel.Disabledpermite que la prueba se ejecute a toda velocidad. Pero también desactiva la magia (¡lenta!) Que espera hasta que sea seguro interactuar con los controles de la página.Establecer un
MaximumRetryCounty adjuntar un controlador de errores resuelve la mayoría de los errores que resultan de la desactivación de la magia "esperar a que esté listo". Debido a que he incorporado unSleep1 segundo en la lógica de reintento, este valor es efectivamente el número de segundos que estoy dispuesto a esperar a que la página se cargue y responda.Aparentemente, no encontrar el control bajo prueba no es uno de los errores manejados por el controlador de errores / mecanismo de reintento. Si la nueva página tarda más de unos pocos segundos en cargarse, y la prueba está buscando un control que no existe hasta que se carga la nueva página, la prueba no encuentra el control y la prueba falla. La configuración
ShouldSearchFailFast = falseresuelve ese problema dándole el tiempo de espera completo para que su página se cargue.La configuración de
DelayBetweenActions = 500parece solucionar un problema que veo ocasionalmente cuando la interfaz de usuario pierde un clic en el botón que se produce inmediatamente después de que se haya cargado una página. La maquinaria de prueba parece pensar que se hizo clic en el botón, pero la página web no responde.La "documentación" dice que el tiempo de espera de búsqueda predeterminado es de 3 minutos, pero en realidad es más de 10 minutos, así que configuro
SearchTimeoutexplícitamente en 1 segundo (1000 ms).
Para mantener todo el código en un solo lugar, he creado una clase que contiene el código utilizado por todas las pruebas. MyCodedUITests.StartTest() es llamado por el método [TestInitialize] en cada una de mis clases de prueba.
Este código realmente debería ejecutarse solo una vez para todas las pruebas (en lugar de una por prueba), pero no pude encontrar una manera de hacer que las llamadas Playback.PlaybackSettings funcionen en las rutinas [AssemblyInitialization] o [ClassInitialization] .
/// <summary> A class containing Coded UI Tests. </summary>
[CodedUITest]
public class UI_Tests
{
/// <summary> Common initialization for all of the tests in this class. </summary>
[TestInitialize]
public void TestInit()
{
// Call a common routine to set up the test
MyCodedUITests.StartTest();
}
/// <summary> Some test. </summary>
[TestMethod]
public void SomeTest()
{
this.UIMap.Assert_HomePageElements();
this.UIMap.Recorded_DoSomething();
this.UIMap.Assert_FinalPageElements();
}
}
/// <summary> Coded UI Test support routines. </summary>
class MyCodedUITests
{
/// <summary> Test startup. </summary>
public static void StartTest()
{
// Configure the playback engine
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;
Playback.PlaybackSettings.MaximumRetryCount = 10;
Playback.PlaybackSettings.ShouldSearchFailFast = false;
Playback.PlaybackSettings.DelayBetweenActions = 500;
Playback.PlaybackSettings.SearchTimeout = 1000;
// Add the error handler
Playback.PlaybackError -= Playback_PlaybackError; // Remove the handler if it''s already added
Playback.PlaybackError += Playback_PlaybackError; // Ta dah...
}
/// <summary> PlaybackError event handler. </summary>
private static void Playback_PlaybackError(object sender, PlaybackErrorEventArgs e)
{
// Wait a second
System.Threading.Thread.Sleep(1000);
// Retry the failed test operation
e.Result = PlaybackErrorOptions.Retry;
}
}
La IU codificada busca los controles en la pantalla y esa búsqueda es bastante rápida si tiene éxito. Sin embargo, si la búsqueda falla, la IU codificada tiene otro intento de usar un método de "coincidencia inteligente" y eso puede ser lento. La forma básica de evitar que la IU codificada recurra al uso de la coincidencia inteligente es eliminar o simplificar los elementos de búsqueda que pueden cambiar de una ejecución a otra.
Este blog de Microsoft ofrece muchas explicaciones sobre lo que sucede y cómo solucionarlo. El ejemplo en el que se muestra una aceleración de 30 segundos a 8 segundos cambiando una cadena de búsqueda de
Name EqualsTo “Sales order (1 - ceu) - Sales order: SO-101375, Forest Wholesales”
a
Name Contains “Sales order (1 - ceu) - Sales order: SO”
Parece que está capturado desde la herramienta de Microsoft Dynamics. Por favor, compruebe la longitud de la cadena capturada de la herramienta de inspección. Encontrarás algún personaje oculto. solo orden (1 - ceu). De lo contrario, mueva el cursor de "(" a ")". Encontrará que el cursor no se está moviendo en algún momento al presionar la tecla de flecha derecha.