AntiPatrones en testing de Aceptación Automatizado (ATDD)


En esta entrada vamos a revisar que practicas son nocivas cuando aplicamos ATDD mas alla de la herramienta que usemos.

No usar Page-objects

Ya hablamos del patrón Page-Object en un post anterior. No usar este patrón genera complejidad en el código y no permite escalar las pruebas de una forma que no se vuelva un código inmantenible. En el mismo post hay un ejemplo donde se muestra la diferencia de implementación Con Page-Object y Sin Page-Object

Set-up complejo y extenso

Las pruebas de aceptación deben ir directo al grano, y deben verificar funcionalidades especificas, las pruebas mas extensas se ubican en la capa de UI ya que llevan mas tiempo y solo se incluyen caminos claves (Money Path, Regression, Critical bugs).

Buscamos que las pruebas de aceptación nos den un feedback inmediato ya que las mismas se correrán en cada refactor y cada vez que se introduzcan cambios en el servidor CI.

Mal:

Escenario: Compra se realiza con éxito

Dado que estoy en la pagina principal del carrito de compras
Y seleccioné el menú de Electrónicos
Y seleccioné un smartphone
Y lo agregue al carrito de compras
Cuando elegí realizar compra
Y confirmo la compra
Entonces la compra se realiza

Bien:

Escenario: Compra se realiza con éxito

Dado que estoy en la pagina de checkout
Cuando confirmo la compra
Entonces la compra se realiza

Uso inadecuado de los Locators

Es importante tener una estrategia clara para el armado de selectores, ya que los mismos van a determinar en gran porcentaje el costo de mantención de los tests (porque los mayores cambios se dan desde la UI). Los selectores mas robustos son ID y Class, seguidos por CSS Selectors y XPath Selectors. En cuanto a estos últimos, es necesario que el selector se pueda leer y entender fácilmente y que el mismo no depende de otros elementos en exceso, ya que lo hacen extremadamente frágil.

Mal:

private static readonly By ElementSelector= By.CSSSelector(“#input-x > div > div.YSearchRow > div.YSearchCell.no > div:nth-child(2) > label”);

Bien:

private static readonly By TeaTypeSelector = By.Id(“teaType”);

Ejecutar directamente JavaScript

Dado que WebDriver puede ejecutar JavaScript en forma directa, se puede caer en la tentación de saltar la ejecución de ese JavaScript desde el DOM de la aplicación y ejecutarlo directamente desde el test. Es mejor localizar el elemento que ejecuta el JavaScript y que el mismo se accione por la actividad sobre este.

Mal:

public void RemoveX(string xType)
{
(driver as IJavaScriptExecutor).ExecuteScript(string.Format(“viewModel.x.types.removeXType(\”{0}\”);”, xType));
}

Bien:

public void RemoveX(string xType)
{
driver.FindElement(By.Id(“remove-“+xType)).Click();
}

Incluir Detalles de la Implementación

En las pruebas de aceptación se busca el equilibrio entre el lenguaje técnico y el lenguaje del business, pero siempre es importante no mezclar detalles de implementación en las pruebas.

Mal:

Escenario: Links de redes sociales se muestran en la pagina principal

Dado que el usuario esta en la pagina principal

Entonces se muestra el link http://twitter.com

Y se muestra el link http://facebook.com

Bien:

Escenario: Links de redes sociales se muestran en la pagina principal

Dado que el usuario esta en la pagina principal

Entonces se muestra el link a la cuenta de Twitter

Y se muestra el link a la cuenta de Facebook

Escenarios escritos como Test Funcionales tradicionales

En algún punto se puede perder el objetivo mas importante de estas pruebas que es involucrar al cliente en la definición de los escenarios para entender que y porque lo verificamos. Cuando se llega a ese punto los escenarios empiezan a ser muy detallados lo que los transforma en algo muy difícil de entender para los no testers y muy difícil de mantener también, así como perder el foco de que se esta verificando. Es importante transmitir fácil y rápidamente los criterios de aceptación .

Mal:

Escenario: La compra se realiza con éxito

Dado que estoy en la pagina de checkout

Y tengo el elemento TestElement1

Y tengo el elemento TestElement2

Cuando confirmo la compra

Entonces la compra se realiza

Y la base de datos muestra el TestElement1

Y la base de datos muestra el TestElement2

Y el usuario es redireccionado a la pagina de compra satisfactoria

Y el carrito de compras es vaciado

Bien:

Escenario: Compra se realiza con éxito

Dado que estoy en la pagina de checkout
Cuando confirmo la compra
Entonces la compra se realiza

Ausencia de reporte de resultados

Desafortunadamente algunos equipos ponen mucho esfuerzo en hacer las pruebas de aceptación pero no ponen ninguna atención en generar y publicar un reporte con  los resultados de las pruebas. Esto hace que las pruebas se conviertan en  pseudo ‘pruebas de unidad ” solo destinadas a desarrolladores. Perdiéndose los beneficios reales de una mayor colaboración con el equipo y el cliente.

¿Agregarías algún otro antipatron? Compártelo en los comentarios!

Te gustó el post? Quieres contribuir para que escriba más? Contribute with the Blog

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s