Pruebas inestables: deshacerse de una pesadilla viviente en las pruebas

 

 

 

  • SmashingConf Nueva York 2024
  • Clase magistral de tipografía, con Elliot Jay Stocks

  • Índice
    1. Pruebas de front-end: ¿Por qué molestarse?
    2. La ciencia de las pruebas inestables
    3. Las causas
      1. 1. Causas del lado de la prueba
      2. 2. Causas del lado ambiental
      3. 3. Causas del lado del producto
    4. Formas de combatir la descamación
      1. Concéntrate en tu equipo
      2. Mantenga las pruebas aisladas
      3. Optimice aún más la estructura de la prueba
      4. ¡Esperar! ¿Los reintentos de prueba a veces son correctos?
      5. Usar tiempos de espera dinámicos
      6. Depuración de pruebas inestables
    5. ¡Lucha contra las pesadillas de la descamación!
      1. Detectar las banderas rojas
      2. Otras lecturas

    Las pruebas poco fiables son una pesadilla para cualquiera que escriba pruebas automatizadas o preste atención a los resultados. Las pruebas inestables incluso han provocado que la gente tenga pesadillas y noches de insomnio. En este artículo, Ramona Schwering comparte sus experiencias para ayudarte a salir de este infierno o evitar caer en él.

     

    Hay una fábula en la que pienso mucho estos días. La fábula me la contaron cuando era niño. Se llama "El niño que gritó lobo" de Esopo. Se trata de un niño que cuida las ovejas de su pueblo. Se aburre y finge que un lobo está atacando al rebaño, pidiendo ayuda a los aldeanos, solo para que ellos se den cuenta, decepcionados, de que es una falsa alarma y dejen al niño en paz. Luego, cuando aparece un lobo y el niño pide ayuda, los aldeanos creen que es otra falsa alarma y no acuden al rescate, y las ovejas terminan siendo devoradas por el lobo.

     

    La moraleja de la historia la resume mejor el propio autor:

    “Al mentiroso no se le creerá, aunque diga la verdad”.

    Un lobo ataca a las ovejas y el niño pide ayuda a gritos, pero después de numerosas mentiras, ya nadie le cree. Esta moraleja se puede aplicar a las pruebas: la historia de Esopo es una bonita alegoría de un patrón coincidente con el que me topé: pruebas poco fiables que no proporcionan ningún valor.

    Pruebas de front-end: ¿Por qué molestarse?

    La mayor parte de mis días los paso realizando pruebas de front-end. Por lo tanto, no debería sorprenderle que los ejemplos de código de este artículo provengan principalmente de las pruebas de front-end que he encontrado en mi trabajo. Sin embargo, en la mayoría de los casos, se pueden traducir fácilmente a otros idiomas y aplicar a otros marcos. Espero que el artículo le resulte útil, sea cual sea su experiencia.

    Vale la pena recordar qué significan las pruebas iniciales. En esencia, las pruebas front-end son un conjunto de prácticas para probar la interfaz de usuario de una aplicación web, incluida su funcionalidad.

    Al comenzar como ingeniero de control de calidad, conozco el dolor de las interminables pruebas manuales a partir de una lista de verificación justo antes de un lanzamiento. Entonces, además del objetivo de garantizar que una aplicación permanezca libre de errores durante las sucesivas actualizaciones, me esforcé por aliviar la carga de trabajo de las pruebas causadas por aquellas tareas rutinarias para las que en realidad no se necesita un humano. Ahora, como desarrollador, encuentro que el tema sigue siendo relevante, especialmente porque trato de ayudar directamente tanto a los usuarios como a los compañeros de trabajo. Y hay un problema con las pruebas en particular que nos ha provocado pesadillas.

    La ciencia de las pruebas inestables

    Una prueba inestable es aquella que no produce el mismo resultado cada vez que se ejecuta el mismo análisis. La compilación fallará solo ocasionalmente: una vez pasará, otra vez fallará y la próxima vez volverá a pasar, sin que se haya realizado ningún cambio en la compilación.

    Cuando recuerdo mis pesadillas con los exámenes, me viene a la mente un caso en particular. Fue en una prueba de UI. Creamos un cuadro combinado con estilo personalizado (es decir, una lista seleccionable con campo de entrada):

    Un selector personalizado en un proyecto en el que trabajé todos los días. ( Vista previa grande )

    Con este cuadro combinado, puede buscar un producto y seleccionar uno o más de los resultados. Muchos días esta prueba salió bien, pero en algún momento las cosas cambiaron. En una de las aproximadamente diez compilaciones de nuestro sistema de integración continua (CI), la prueba para buscar y seleccionar un producto en este cuadro combinado falló.

    La captura de pantalla del fallo muestra que la lista de resultados no se filtra, a pesar de que la búsqueda ha sido exitosa:

     

    Prueba inestable en acción: ¿por qué falla sólo a veces y no siempre? ( Vista previa grande )

    Una prueba deficiente como esta puede bloquear el proceso de implementación continua , haciendo que la entrega de funciones sea más lenta de lo necesario. Además, una prueba inestable es problemática porque ya no es determinista, lo que la hace inútil. Después de todo, no confiarías en nadie más de lo que confiarías en un mentiroso.

    Además, las pruebas deficientes son costosas de reparar y a menudo requieren horas o incluso días para depurarlas. Aunque las pruebas de un extremo a otro son más propensas a ser inestables, las he experimentado en todo tipo de pruebas: pruebas unitarias, pruebas funcionales, pruebas de un extremo a otro y todo lo demás.

    Otro problema importante con las pruebas inestables es la actitud que nos infunden a los desarrolladores. Cuando comencé a trabajar en la automatización de pruebas, a menudo escuchaba a los desarrolladores decir esto en respuesta a una prueba fallida:

    “Ahh, esa construcción. No importa, simplemente comienza de nuevo. Eventualmente pasará, en algún momento”.

    Esta es una gran señal de alerta para mí . Me muestra que el error en la compilación no se tomará en serio. Existe la suposición de que una prueba inestable no es un error real, sino que es “simplemente” inestable, sin necesidad de ser atendida o incluso depurada. La prueba volverá a pasar más tarde de todos modos, ¿verdad? ¡No! Si se fusiona dicha confirmación, en el peor de los casos tendremos una nueva prueba inestable en el producto.

    Las causas

    Entonces, las pruebas inestables son problemáticas. ¿Qué debemos hacer al respecto? Bueno, si conocemos el problema, podemos diseñar una contraestrategia.

    A menudo encuentro causas en la vida cotidiana. Se pueden encontrar dentro de las propias pruebas . Las pruebas pueden estar escritas de manera subóptima, contener suposiciones erróneas o contener malas prácticas. Sin embargo, no sólo eso. Las pruebas deficientes pueden ser un indicio de algo mucho peor.

    En las siguientes secciones, repasaremos los más comunes con los que me he encontrado.

    1. Causas del lado de la prueba

    En un mundo ideal, el estado inicial de su aplicación debería ser impecable y 100% predecible. En realidad, nunca se sabe si la identificación que utilizó en su prueba será siempre la misma.

    Inspeccionemos dos ejemplos de un solo fallo de mi parte. El error número uno fue usar una identificación en mis dispositivos de prueba:

    { "id": "f1d2554b0ce847cd82f3ac9bd1c0dfca", "name": "Variant product",}

    El error número dos fue buscar un selector único para usar en una prueba de interfaz de usuario y pensar: "Está bien, esta identificación parece única". Lo usaré”.

     

    !-- This is a text field I took from a project I worked on --input type="text" /

    Sin embargo, si ejecutara la prueba en otra instalación o, más adelante, en varias compilaciones de CI, esas pruebas podrían fallar. Nuestra aplicación generaría las ID nuevamente y las cambiaría entre compilaciones. Entonces, la primera causa posible se encuentra en las identificaciones codificadas .

    La segunda causa puede surgir de datos de demostración generados aleatoriamente (o de otra manera) . Claro, podría estar pensando que este "defecto" está justificado (después de todo, la generación de datos es aleatoria), pero piense en depurar estos datos. Puede resultar muy difícil ver si un error se encuentra en las pruebas mismas o en los datos de demostración.

    El siguiente paso es una causa del lado de las pruebas con la que he luchado numerosas veces: pruebas con dependencias cruzadas . Es posible que algunas pruebas no puedan ejecutarse de forma independiente o en orden aleatorio, lo cual es problemático. Además, las pruebas anteriores podrían interferir con las posteriores. Estos escenarios pueden provocar pruebas inestables al introducir efectos secundarios.

    Sin embargo, no olvide que las pruebas consisten en cuestionar suposiciones . ¿Qué sucede si, para empezar, sus suposiciones son erróneas? He experimentado esto a menudo, siendo mi favorito las suposiciones erróneas sobre el tiempo.

    Un ejemplo es el uso de tiempos de espera inexactos, especialmente en pruebas de interfaz de usuario (por ejemplo, mediante el uso de tiempos de espera fijos ). La siguiente línea está tomada de una prueba de Nightwatch.js .

    // Please never do that unless you have a very good reason!// Waits for 1 secondbrowser.pause(1000);

    Otra suposición errónea se relaciona con el tiempo mismo. Una vez descubrí que una prueba PHPUnit inestable fallaba solo en nuestras compilaciones nocturnas. Después de un poco de depuración, descubrí que el culpable fue el cambio de tiempo entre ayer y hoy. Otro buen ejemplo son los fallos por zonas horarias .

    Las falsas suposiciones no terminan ahí. También podemos tener suposiciones erróneas sobre el orden de los datos . Imagine una cuadrícula o lista que contenga múltiples entradas con información, como una lista de monedas:

    Un componente de lista personalizado utilizado en nuestro proyecto. ( Vista previa grande )

    Queremos trabajar con la información de la primera entrada, la moneda “corona checa”. ¿Puede estar seguro de que su aplicación siempre colocará este dato como la primera entrada cada vez que se ejecute su prueba? ¿Será que el “euro” u otra moneda será la primera entrada en algunas ocasiones?

    No asuma que sus datos vendrán en el orden en que los necesita. De manera similar a las identificaciones codificadas, un orden puede cambiar entre compilaciones, según el diseño de la aplicación.

    2. Causas del lado ambiental

    La siguiente categoría de causas se relaciona con todo lo que está fuera de sus pruebas. Específicamente, estamos hablando del entorno en el que se ejecutan las pruebas, las dependencias relacionadas con CI y Docker fuera de sus pruebas; todas esas cosas en las que apenas puede influir, al menos en su rol de evaluador.

     

    Una causa común del lado del entorno son las fugas de recursos : a menudo, se trata de una aplicación bajo carga, lo que provoca tiempos de carga variables o comportamientos inesperados. Las pruebas grandes pueden causar fácilmente fugas y consumir mucha memoria. Otro problema común es la falta de limpieza .

    La incompatibilidad entre dependencias me da pesadillas en particular. Ocurrió una pesadilla cuando estaba trabajando con Nightwatch.js para realizar pruebas de interfaz de usuario. Nightwatch.js usa WebDriver, que por supuesto depende de Chrome. Cuando Chrome avanzó rápidamente con una actualización, hubo un problema de compatibilidad: Chrome, WebDriver y Nightwatch.js ya no funcionaban juntos, lo que provocaba que nuestras compilaciones fallaran de vez en cuando.

    Hablando de dependencias : una mención de honor para cualquier problema de npm, como permisos faltantes o npm inactivo. Experimenté todo esto al observar CI.

    Cuando se trata de errores en las pruebas de UI debido a problemas ambientales, tenga en cuenta que necesita toda la pila de aplicaciones para que se ejecuten. Cuantas más cosas estén involucradas, mayor será el potencial de error . Las pruebas de JavaScript son, por tanto, las pruebas más difíciles de estabilizar en el desarrollo web, porque cubren una gran cantidad de código.

    3. Causas del lado del producto

    Por último, pero no menos importante, debemos tener mucho cuidado con esta tercera área: un área con errores reales. Me refiero a las causas de descamación del producto. Uno de los ejemplos más conocidos son las condiciones de carrera en una aplicación. Cuando esto sucede, el error debe corregirse en el producto, no en la prueba. Intentar arreglar la prueba o el entorno no servirá de nada en este caso.

    Formas de combatir la descamación

    Hemos identificado tres causas de descamación. ¡Podemos construir nuestra contraestrategia sobre esto! Por supuesto, ya habrá ganado mucho si tiene en cuenta las tres causas cuando se encuentre con pruebas deficientes. Ya sabrás qué buscar y cómo mejorar las pruebas. Sin embargo, además de esto, existen algunas estrategias que nos ayudarán a diseñar, escribir y depurar pruebas, y las veremos juntas en las siguientes secciones. Estufa de pellets

    Concéntrate en tu equipo

    Su equipo es posiblemente el factor más importante . Como primer paso, admita que tiene un problema con las pruebas inestables. ¡Conseguir el compromiso de todo el equipo es crucial! Luego, como equipo, deben decidir cómo lidiar con las pruebas inestables.

    Durante los años que trabajé en tecnología, me encontré con cuatro estrategias utilizadas por los equipos para contrarrestar la debilidad:

    1. No haga nada y acepte el resultado inestable de la prueba.
      Por supuesto, esta estrategia no es una solución en absoluto. La prueba no arrojará ningún valor porque ya no puedes confiar en ella, incluso si aceptas su debilidad. Así que podemos saltarnos este con bastante rapidez.
    2. Vuelva a intentar la prueba hasta que pase.
      Esta estrategia era común al comienzo de mi carrera, lo que resultó en la respuesta que mencioné anteriormente. Hubo cierta aceptación al volver a intentar las pruebas hasta que se aprobaron. Esta estrategia no requiere depuración, pero es vaga. Además de ocultar los síntomas del problema, ralentizará aún más su conjunto de pruebas, lo que hace que la solución no sea viable. Sin embargo, puede haber algunas excepciones a esta regla, que explicaré más adelante.
    3. Elimina y olvídate de la prueba.
      Este se explica por sí mismo: simplemente elimine la prueba inestable, para que ya no perturbe su conjunto de pruebas. Claro, le ahorrará dinero porque ya no necesitará depurar ni corregir la prueba. Pero esto se consigue a costa de perder un poco de cobertura de prueba y perder posibles correcciones de errores. ¡La prueba existe por una razón! No dispares al mensajero eliminando la prueba.
    4. Poner en cuarentena y arreglar.
      Tuve el mayor éxito con esta estrategia. En este caso, nos saltaríamos la prueba temporalmente y el conjunto de pruebas nos recordaría constantemente que se ha omitido una prueba. Para asegurarnos de que no se pase por alto la solución, programaremos un ticket para el próximo sprint. Los recordatorios de bots también funcionan bien. Una vez que se haya solucionado el problema que causaba la descamación, integraremos (es decir, cancelaremos la omisión) la prueba nuevamente. Desafortunadamente, perderemos la cobertura temporalmente, pero volverá con una solución, por lo que esto no tomará mucho tiempo.

    Pruebas omitidas, tomadas de un informe de nuestro CI. ( Vista previa grande )

     

    Estas estrategias nos ayudan a lidiar con problemas de prueba a nivel de flujo de trabajo y no soy el único que los ha encontrado. En su artículo, Sam Saffron llega a una conclusión similar . Pero en nuestro trabajo diario nos ayudan de forma limitada. Entonces, ¿cómo procedemos cuando se nos presenta una tarea de este tipo?

    Mantenga las pruebas aisladas

    Al planificar la estructura y los casos de prueba, mantenga siempre las pruebas aisladas de otras pruebas, para que puedan ejecutarse en un orden independiente o aleatorio. El paso más importante es restaurar una instalación limpia entre pruebas . Además, pruebe únicamente el flujo de trabajo que desea probar y cree datos simulados solo para la prueba en sí. Otra ventaja de este atajo es que mejorará el rendimiento de la prueba . Si sigue estos puntos, no se interpondrán efectos secundarios de otras pruebas ni datos sobrantes.

    El siguiente ejemplo está tomado de las pruebas de interfaz de usuario de una plataforma de comercio electrónico y trata sobre el inicio de sesión del cliente en el escaparate de la tienda. (La prueba está escrita en JavaScript, utilizando el marco Cypress ).

    // File: customer-login.spec.jslet customer = {};beforeEach(() = { // Set application to clean state cy.setInitialState() .then(() = { // Create test data for the test specifically return cy.setFixture('customer'); })}):

    El primer paso es restablecer la aplicación a una instalación limpia. Se realiza como el primer paso en el beforeEachciclo de vida para garantizar que el reinicio se ejecute en cada ocasión. Luego, los datos de prueba se crean específicamente para la prueba; para este caso de prueba, se crearía un cliente mediante un comando personalizado. Posteriormente, podemos comenzar con el flujo de trabajo que queremos probar: el inicio de sesión del cliente.

     

    Optimice aún más la estructura de la prueba

    Podemos hacer algunos otros pequeños ajustes para que nuestra estructura de prueba sea más estable. La primera es bastante simple: comience con pruebas más pequeñas. Como se dijo antes, cuanto más hagas en una prueba, más errores pueden salir. Mantenga las pruebas lo más simples posible y evite mucha lógica en cada una.

    Cuando se trata de no asumir un orden de datos (por ejemplo, cuando se trata del orden de las entradas en una lista en las pruebas de UI), podemos diseñar una prueba para que funcione independientemente de cualquier orden. Para volver al ejemplo de la cuadrícula con información, no usaríamos pseudoselectores u otros CSS que tengan una fuerte dependencia del orden. En lugar del nth-child(3)selector, podríamos usar texto u otras cosas cuyo orden no importe. Por ejemplo, podríamos usar una afirmación como "Búscame el elemento con esta cadena de texto en esta tabla".

    ¡Esperar! ¿Los reintentos de prueba a veces son correctos?

    Reintentar las pruebas es un tema controvertido, y con razón. Sigo pensando que es un antipatrón si la prueba se vuelve a intentar a ciegas hasta que tenga éxito. Sin embargo, hay una excepción importante: cuando no puedes controlar los errores, volver a intentarlo puede ser un último recurso (por ejemplo, para excluir errores de dependencias externas). En este caso no podemos influir en el origen del error. Sin embargo, tenga mucho cuidado al hacer esto: no se ciegue ante las irregularidades al volver a intentar una prueba y utilice notificaciones para recordarle cuando se omita una prueba.

    El siguiente ejemplo es uno que utilicé en nuestro CI con GitLab. Otros entornos pueden tener una sintaxis diferente para lograr reintentos, pero esto debería darle una idea:

    test: script: rspec retry: max: 2 when: runner_system_failure

    En este ejemplo, estamos configurando cuántos reintentos se deben realizar si el trabajo falla. Lo interesante es la posibilidad de volver a intentarlo si hay un error en el sistema de ejecución (por ejemplo, falló la configuración del trabajo). Elegimos volver a intentar nuestro trabajo solo si falla algo en la configuración de la ventana acoplable.

    Tenga en cuenta que esto volverá a intentar todo el trabajo cuando se active. Si desea volver a intentar solo la prueba defectuosa, deberá buscar una función en su marco de prueba que lo admita. A continuación se muestra un ejemplo de Cypress, que admite reintentos de una sola prueba desde la versión 5:

    { "retries": { // Configure retry attempts for 'cypress run` "runMode": 2, // Configure retry attempts for 'cypress open` "openMode": 2, }}

    Puede activar los reintentos de prueba en el archivo de configuración de Cypress, cypress.json. Allí puede definir los reintentos en el ejecutor de pruebas y en el modo sin cabeza.

     

    Usar tiempos de espera dinámicos

    Este punto es importante para todo tipo de pruebas, pero especialmente para las pruebas de UI. No puedo enfatizar esto lo suficiente: nunca uses tiempos de espera fijos , al menos no sin una muy buena razón. Si lo haces, considera los posibles resultados. En el mejor de los casos, elegirá tiempos de espera demasiado largos, lo que hará que el conjunto de pruebas sea más lento de lo necesario. En el peor de los casos, no esperará lo suficiente, por lo que la prueba no continuará porque la aplicación aún no está lista, lo que provocará que la prueba falle de manera inestable. En mi experiencia, esta es la causa más común de pruebas inestables.

    En su lugar, utilice tiempos de espera dinámicos. Hay muchas maneras de hacerlo, pero Cypress las maneja particularmente bien.

    Todos los comandos de Cypress poseen un método de espera implícito: ya verifican si el elemento al que se aplica el comando existe en el DOM durante el tiempo especificado, lo que apunta a la capacidad de reintento de Cypress. Sin embargo, sólo comprueba la existencia y nada más. Por lo tanto, recomiendo ir un paso más allá: esperar cualquier cambio en la interfaz de usuario de su sitio web o aplicación que un usuario real también vería, como cambios en la interfaz de usuario misma o en la animación.

    Un tiempo de espera fijo, que se encuentra en el registro de pruebas de Cypress. ( Vista previa grande )

    Este ejemplo utiliza un tiempo de espera explícito en el elemento con el selector .offcanvas. La prueba solo continuará si el elemento es visible hasta el tiempo de espera especificado, que puedes configurar:

    // Wait for changes in UI (until element is visible)cy.get(#element).should('be.visible');

    Otra buena posibilidad en Cypress para la espera dinámica son sus características de red. Sí, podemos esperar a que se produzcan solicitudes y a los resultados de sus respuestas. Utilizo este tipo de espera con especial frecuencia. En el siguiente ejemplo, definimos la solicitud a esperar, usamos un waitcomando para esperar la respuesta y afirmamos su código de estado:

    // File: checkout-info.spec.js// Define request to wait forcy.intercept({ url: '/widgets/customer/info', method: 'GET'}).as('checkoutAvailable');// Imagine other test steps here...// Assert the response’s status code of the requestcy.wait('@checkoutAvailable').its('response.statusCode') .should('equal', 200);

    De esta manera, podemos esperar exactamente el tiempo que nuestra aplicación necesita, lo que hace que las pruebas sean más estables y menos propensas a fallas debido a fugas de recursos u otros problemas ambientales.

    Depuración de pruebas inestables

    Ahora sabemos cómo evitar pruebas inestables mediante el diseño. Pero, ¿qué pasa si ya estás lidiando con una prueba inestable? ¿Cómo puedes deshacerte de él?

    Cuando estaba depurando, poner la prueba defectuosa en un bucle me ayudó mucho a descubrir la debilidad. Por ejemplo, si ejecuta una prueba 50 veces y pasa cada vez, entonces puede estar más seguro de que la prueba es estable; tal vez su solución funcionó. De lo contrario, al menos podrá obtener más información sobre la prueba inestable.

     

    // Use in build Lodash to repeat the test 100 timesCypress._.times(100, (k) = { it(`typing hello ${k + 1} / 100`, () = { // Write your test steps in here })})

    Obtener más información sobre esta prueba inestable es especialmente difícil en CI. Para obtener ayuda, vea si su marco de pruebas puede obtener más información sobre su compilación. Cuando se trata de pruebas de front-end, normalmente puedes utilizar console.logen tus pruebas:

    it('should be a Vue.JS component', () = { // Mock component by a method defined before const wrapper = createWrapper(); // Print out the component’s html console.log(wrapper.html()); expect(wrapper.isVueInstance()).toBe(true);})

    Este ejemplo está tomado de una prueba unitaria de Jest en la que utilizo a console.logpara obtener el resultado del HTML del componente que se está probando. Si utiliza esta posibilidad de registro en el ejecutor de pruebas de Cypress, puede incluso inspeccionar el resultado en las herramientas de desarrollo que elija. Además, cuando se trata de Cypress en CI, puede inspeccionar esta salida en el registro de su CI mediante el uso de un complemento.

    Mire siempre las características de su marco de prueba para obtener ayuda con el registro. En las pruebas de interfaz de usuario, la mayoría de los marcos proporcionan funciones de captura de pantalla ; al menos en caso de falla, se tomará una captura de pantalla automáticamente. Algunos marcos incluso proporcionan grabación de video , lo que puede ser de gran ayuda para obtener información sobre lo que sucede en la prueba.

    ¡Lucha contra las pesadillas de la descamación!

    Es importante buscar continuamente pruebas deficientes, ya sea previniéndolas en primer lugar o depurándolas y corrigiéndolas tan pronto como ocurren. Necesitamos tomarlos en serio, porque pueden indicar problemas en su aplicación.

    Detectar las banderas rojas

    Por supuesto, lo mejor es prevenir las pruebas inestables en primer lugar. Para resumir rápidamente, aquí hay algunas señales de alerta:

    • La prueba es extensa y contiene mucha lógica.
    • La prueba cubre una gran cantidad de código (por ejemplo, en pruebas de UI).
    • La prueba utiliza tiempos de espera fijos.
    • La prueba depende de pruebas anteriores.
    • La prueba afirma datos que no son 100% predecibles, como el uso de ID, tiempos o datos de demostración, especialmente los generados aleatoriamente.

    Si tiene en cuenta los consejos y estrategias de este artículo, podrá evitar pruebas fallidas antes de que sucedan. Y si llegan, sabrá cómo depurarlos y solucionarlos.

    Estos pasos realmente me han ayudado a recuperar la confianza en nuestro conjunto de pruebas. Nuestro conjunto de pruebas parece estable en este momento. Podría haber problemas en el futuro: nada es 100 % perfecto. Este conocimiento y estas estrategias me ayudarán a afrontarlos. Por lo tanto, tendré más confianza en mi capacidad para luchar contra esas pesadillas de pruebas inestables .

    ¡Espero haber podido aliviar al menos algo de su dolor y preocupaciones sobre la descamación!

    Otras lecturas

    Si desea obtener más información sobre este tema, aquí hay algunos recursos y artículos interesantes que me ayudaron mucho:

    • Artículos sobre “ flake ”, Cypress.io
    • “ Volver a realizar las pruebas es realmente algo bueno (si su enfoque es correcto) ”, Filip Hric, Cypress.io
    • “ Prueba de descamación: métodos para identificar y tratar pruebas de descamación ”, Jason Palmer, Ingeniería de I+D de Spotify
    • " Pruebas inestables en Google y cómo las mitigamos ", John Micco, Blog de pruebas de Google

    (vf, il, al)Explora más en

    • interfaz de usuario
    • Herramientas
    • Pruebas
    • javascript





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Pruebas inestables: deshacerse de una pesadilla viviente en las pruebas

    Pruebas inestables: deshacerse de una pesadilla viviente en las pruebas

    SmashingConf Nueva York 2024 Clase magistral de tipografía, con Elliot Jay Stocks Índice Pruebas de fron

    programar

    es

    https://aprendeprogramando.es/static/images/programar-pruebas-inestables-deshacerse-de-una-pesadilla-viviente-en-las-pruebas-1090-0.jpg

    2024-05-21

     

    Pruebas inestables: deshacerse de una pesadilla viviente en las pruebas
    Pruebas inestables: deshacerse de una pesadilla viviente en las pruebas

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20