Coincido que cuanto mas arriba de la piramide de automotion, menos mocks usar. Pero hay veces que incluso en el E2E no pueden usarse los datos reales, en mi trabajo pasa frecuentemente y por lo tanto es común encontrar bugs en producción. Lo ideal seria que todo este correctamente definido y que el mock sea lo menos dummy posible. Pero todo cuesta guita. Por lo que entendí de tu ejemplo, ese caso de error se debería pescar con las pruebas de la API, a partir de ahí tener definido correctamente el mock para evitar mandar fruta que nunca podría enviarse en el ambiente real. Gran video Pato! Me encantó la temática.
Yo uso mocks más que nada para probar la parte UI del E2E, para asegurarnos de que lo que viene de la API se muestre correctamente en la UI (lo que solo tiene sentido si ya existe la integración y por lo tanto podemos interceptar las llamadas). En mi opinión, para probar la API en sí es mejor crear una test suite para probar los endpoints directamente, sin necesidad de correr el front.
como analista tomé la práctica de crear mocks de apis REST y SOAP, de ambientes a los que el equipo no tenía acceso, así ellos pueden desarrollar y probar y con eso la integración es mucho más suave... y es que el chiste es que los mocks no siempre son hardcodeados, mocks como los que hago son dinámicos, de alta definición, y de hecho he estado avanzando en hacerlos configurables al vuelo modificado el mockservice runner de SoapUI.
en desarrollo cualquier prueba es una simulación, así que, qué mejor que puedas probar con mocks todos los escenarios significativos de éxito pero más los escenarios de error, incluso aquellos que son muy difíciles de replicar.
Gracias!!! Pero tenemos que dar crédito a la única e inigualable Waifu que es la editora del canal y cursos ahora! Yo solo me planto frente a la cámara y les cuento cosas/viajo!
Hay algo que dijo john fergurson smart (creo) y es que todos tus tests deben de fallar, incluso si son de Automation ya que si no no estarian aportando valor al negocio. Asi que aqui va mi forma de verlo mejor que tus tests fallen y puedan descubrir errores a que pasen y no se sepa que esta fallando, por eso yo tambien realizo test a nivel de API en el e2e y reviso que se puedan vizuarlizar en la UI y no solo que la UI se vea bonita, porque luego pasa que si la API funciona mal el cliente se va a quejar de igual forma... Ya me paso que el equipo de producto solo se preocupaba de que la UI saliera bien y no entendian o no querian entender que si la API funciona mal no importa que tan lindo se viese la UI porque nada iba a salir bien... se aprendio a los porrazos.
A ver...no se si todos tus tests deben fallar. Todos tienen que estar bien hechos de manera tal que fallen si las cosas no van bien. Mirá...te cuento una historia que me pasó ayer. Yo había automatizado unas pruebas en API con Mocha. Siempre, mientras hago las pruebas, exploro bastante la API y aparte hago fallar a propósito las pruebas haciendo assertions contrarias a lo que quiero probar. Cuestión que estaban joya, funcionando para un bugfix medio nefasto que habíamos hecho. La manera en que trabaja el equipo es que yo hago branch del feature branch del dev para la historia y ese branch es el que se deployea en una instancia exclusiva con esos cambios. Todo funcionaba joya. Ahora...el dev estaba trabajando en otra historia, otro branch, mismo codebase (una mala idea posiblemente) y también hizo merge de ese branch al main. Las pruebas, de repente, fallaban. Me dicen "Pato, hay 3 pruebas fallando en el pipeline cuando queremos hacer el deploy". Cuando veo las 3 pruebas, eran las que había hecho para el bugfix. Cuando miro el output en el reporte, las pruebas estaban fallando con razón: El bug seguía pasando! Cuestión, no se qué malabar de branches había hecho el dev, pero había dado marcha atrás el bugfix en main, pisando este cambio con el que hizo después y las pruebas obviamente estaban levantando la mano porque algo no estaba bien. Si las pruebas no fallaban...el bugfix iba a Prod y nos íbamos a enterar cuando el cliente dijese "che...pero esto sigue fallando!"
Por mas videos con codigo!!!!! excelente 😀. BUEN VIDEOOOO , gracias Pato
Sabés que son los que más me gusta hacer. Vamos a meterle más a este tipo de contenido.
Coincido que cuanto mas arriba de la piramide de automotion, menos mocks usar. Pero hay veces que incluso en el E2E no pueden usarse los datos reales, en mi trabajo pasa frecuentemente y por lo tanto es común encontrar bugs en producción.
Lo ideal seria que todo este correctamente definido y que el mock sea lo menos dummy posible.
Pero todo cuesta guita.
Por lo que entendí de tu ejemplo, ese caso de error se debería pescar con las pruebas de la API, a partir de ahí tener definido correctamente el mock para evitar mandar fruta que nunca podría enviarse en el ambiente real.
Gran video Pato! Me encantó la temática.
Me gusta traer estos debates que tengo a veces conmigo mismo a raíz de un día de trabajo. Gracias por tu comentario!
Yo uso mocks más que nada para probar la parte UI del E2E, para asegurarnos de que lo que viene de la API se muestre correctamente en la UI (lo que solo tiene sentido si ya existe la integración y por lo tanto podemos interceptar las llamadas). En mi opinión, para probar la API en sí es mejor crear una test suite para probar los endpoints directamente, sin necesidad de correr el front.
Una estrategia válida sin dudas. Para probar UI pura y dura mockear re va
Las intro de tus videos son lo mas Pato!
Me alegro que te gusten!!!
como analista tomé la práctica de crear mocks de apis REST y SOAP, de ambientes a los que el equipo no tenía acceso, así ellos pueden desarrollar y probar y con eso la integración es mucho más suave... y es que el chiste es que los mocks no siempre son hardcodeados, mocks como los que hago son dinámicos, de alta definición, y de hecho he estado avanzando en hacerlos configurables al vuelo modificado el mockservice runner de SoapUI.
en desarrollo cualquier prueba es una simulación, así que, qué mejor que puedas probar con mocks todos los escenarios significativos de éxito pero más los escenarios de error, incluso aquellos que son muy difíciles de replicar.
Alta presentación Pato, felicitaciones, y el contenido impecable.
Gracias!!! Pero tenemos que dar crédito a la única e inigualable Waifu que es la editora del canal y cursos ahora! Yo solo me planto frente a la cámara y les cuento cosas/viajo!
Hay algo que dijo john fergurson smart (creo) y es que todos tus tests deben de fallar, incluso si son de Automation ya que si no no estarian aportando valor al negocio. Asi que aqui va mi forma de verlo mejor que tus tests fallen y puedan descubrir errores a que pasen y no se sepa que esta fallando, por eso yo tambien realizo test a nivel de API en el e2e y reviso que se puedan vizuarlizar en la UI y no solo que la UI se vea bonita, porque luego pasa que si la API funciona mal el cliente se va a quejar de igual forma... Ya me paso que el equipo de producto solo se preocupaba de que la UI saliera bien y no entendian o no querian entender que si la API funciona mal no importa que tan lindo se viese la UI porque nada iba a salir bien... se aprendio a los porrazos.
A ver...no se si todos tus tests deben fallar. Todos tienen que estar bien hechos de manera tal que fallen si las cosas no van bien. Mirá...te cuento una historia que me pasó ayer.
Yo había automatizado unas pruebas en API con Mocha. Siempre, mientras hago las pruebas, exploro bastante la API y aparte hago fallar a propósito las pruebas haciendo assertions contrarias a lo que quiero probar. Cuestión que estaban joya, funcionando para un bugfix medio nefasto que habíamos hecho.
La manera en que trabaja el equipo es que yo hago branch del feature branch del dev para la historia y ese branch es el que se deployea en una instancia exclusiva con esos cambios. Todo funcionaba joya.
Ahora...el dev estaba trabajando en otra historia, otro branch, mismo codebase (una mala idea posiblemente) y también hizo merge de ese branch al main. Las pruebas, de repente, fallaban.
Me dicen "Pato, hay 3 pruebas fallando en el pipeline cuando queremos hacer el deploy". Cuando veo las 3 pruebas, eran las que había hecho para el bugfix. Cuando miro el output en el reporte, las pruebas estaban fallando con razón: El bug seguía pasando!
Cuestión, no se qué malabar de branches había hecho el dev, pero había dado marcha atrás el bugfix en main, pisando este cambio con el que hizo después y las pruebas obviamente estaban levantando la mano porque algo no estaba bien.
Si las pruebas no fallaban...el bugfix iba a Prod y nos íbamos a enterar cuando el cliente dijese "che...pero esto sigue fallando!"
Los Mocks son objectos simulados, verdad?.
Exacto!