Feda /dev/ - No Javascript allowed

no se pa q quereis tests de integracion o unitarios,

e2e, si funciona eso es que funciona todo, salu2

Los test de integracion solo deberian probar la integracion. Los tests funcionales deberian probar que las cosas funcionan en conjunto. Los test unitarios hace mucho que los veo un poco estupidos de la manera que lo hace la gente.

fuzz testing, sin duda...

#57103 bueno es integración, el fuzz se refiere a la metodología de como generas el testing, no tiene nada que ver con el testing en si.

tener fuzz testing unitario sirve como documentación, pero si no se usa en ningún test de integracion en tu sistema, es papel mojado.

#57104 te equivoca con ese razonamiento lógico porque lo planteas del revés.

tu SI o SI vas a tener que validar los body, header, path, y SI o SI vas a necesitar un test de integración.

#57108 De nuevo lo estas mirando del revés.

Tu si o si vas a tener un test de integracion que comprobara todo. Si quieres ademas comprobar la logica de validación, tienes que añadir los 3-4 casos de uso que van a fallar.

test call_ping_success;
test call_ping_invalid_body;
test call_ping_invalid_path;
test call_ping_invalid_headers;

Tu ya tienes el entorno preparado, y lo vas a necesitar SI o SI.

De nuevo, si tu no testeas la validación en tu entorno de integracion/acceptance. Te puedo colar bugs cambiando los headers en otro servicio que nunca te darás cuenta.

Si servicio CLIENT llama a PING, y yo hago una PR en CLIENT que tiene su propio repo, desde PING tu no sabes que has cambiado los headers en CLIENT... para eso esta la INTEGRACION.

Si haces el cambio pasan dos cosas:

• breaking change: si tu servicio tiene integracion, detectaras que no puedes cambiar los headers ANTES de desplegar CLIENT a prod
• no breaking: si no pasa nada por ese header, desplegaras CLIENT con la nueva versión

Como has dicho atras, eres muy mal programador. Y estoy de acuerdo.

#57096Kaledros:

Si no eres capaz de evitar ese problema no es que no deberías estar haciendo tests, es que no sabes programar.

Haces codigo de meirda, que se rompe facilmente, que no detecta cambios en los entornos antes de desplegarlo y ademas duplicas codigo lógico en tests unitarios. El pack del fpero al completo. Enhorabuena.

Y lo mismo se puede aplicar en entornos de microservicios donde NO TIENES CD/INTEGRACION CONTINUA. Es decir, que tu Build de master haga re-trigger periódicamente. Si hicieses Build de master periódicamente, si tienes buenos tests de integracion, detectarlas BREAKING CHANGES en otros servicios.

Si por ejemplo tienes CLIENT y PING. Tu cambias CLIENT y nunca tocas PING, no sabes que has roto PING porque no haces ningún cambio en este servicio. PERO, PING hace re-trigger de master cada hora, tu te darás cuenta 1h después de hacer deploy de CLIENT, que has roto algo.

Cuando detectas un breaking change mediante la integracion continua, re-trigger de master periódico, detectas un caso de uso que no tenias testado correctamente en el servicio que has desplegado. Existe un acoplamiento que estas ignorando y por eso se ha roto el codigo. Lo arreglas y nunca mas sucederá. Fácil.

Y en estas cosas, estos acoplamientos y dificultades es donde se ve donde esta una buena arquitectura de una mierda hexagonal FPERA firmada por Miudev que no sabe hacer la O con un canuto.

Ahora que lo leo @desu me recuerda a mi ultimo rollito de verano

#57114 esto me recuerda que tengo alertas de trabajo de linkedin, y en cuanto hay alguna con "fully remote" o "visa sponsored", las solicitudes no bajan de 100.

Que puede parecer desalentador al principio, pero cuando tuve el mes de prueba de linkedin premium pude ver que el 95% eran de pajeets viviendo en india o bangladesh.

#57118 Nosotros también trabajamos así, pensaba que era un estándar.