Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Wei-Yu

el problema es usar los unitarios como si fueran de integración, que es un problema muy común

la pirámide del testing es como la alimenticia

1 respuesta
desu

#57091 sisi uno de los motivos que he dado.

#57090 aqui puse el resumen

La verdad, tener a chatgpt para que ponga mis shitposts algo mas estructurados y coherentes para fperos esta genial jajaja

HeXaN

#57090 Le he pasado este mensaje a mi CTO. A ver si el cabrón deja de ser un FPero.

2
desu

Y el mayor problema es la de educación que fomentan FPeros, universidades e influencers.

Hay que hacer unit testiiiiing, TDDDDDDDD al cuadradooooo...

Y no, la realidad es que los tests unitarios son tests que deben poder borrarse, solo sirven de documentación para el equipo... No es tan complicado de entender y cuando tienes estos fundamentos todo tu codigo de testing y arquitectura mejora exponencialmente.

Todo viene de una mala interpretación de que es un unit tests, porque la idea original de unit tests, es exactamente la que he explicado.... que no he inventando nada HAHAHAHAH Pero con el paso de las décadas se ha re-escrito su significado... por culpa de los gurús e influencers del software corporativo principalmente.

isvidal

no se pa q quereis tests de integracion o unitarios,

e2e, si funciona eso es que funciona todo, salu2

1 respuesta
Kaledros
#57090desu:

Los tests unitarios suelen ser repetitivos y pueden crear una falsa sensación de seguridad

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

4 3 respuestas
Soltrac

#57096 A new challenger appears

desu

#57096 Exactamente, es lo que he dicho, me alegro de que coincidamos en esto.

Por eso le he dicho a 2neuronas que es un mal programador. Porque se que lo es, y su comentario ha venido a confirmar algo que ya sabíamos.

#57095 xq el e2e incluye los de integracion

si tienes buen Coverage de integracion, que debería ser la gran mayoria

los e2e solo son testear cosas de networking

lo malo de tener solo e2e y no integracion es que pierdes modularidad y hay casos de uso de cambios en arquitectura que no se pueden testear en dev/pre/pro. En cambio con integracion SI puedes siempre.

Lecherito

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.

1 respuesta
r2d2rigo

#57088 pues porque tu tienes que meter unos datos en un formato y orden especifico, y si faltan algunos criterios el validador intenta arreglar el estropicio. Los datos van a un repositorio local que se sincroniza a su manera y la API remota hace mas magia aun, aqui no puedes meter ni E2E ni integracion porque como co;o levantas esa infrastructura completa para testear algo que puedes particionar y va a funcionar igual?

desu

#57099 aclaro mi vocabulario

  • unit test
  • integracion que corres en local, si tienes buenos contratos estos se auto-generan y puedes usar como mocks para reducir tiempos de desarollo
    • si corres integracion en dev/pre/pro los llamo acceptance, pero serian tus funcionales creo
  • e2e usar el cliente directamente para comprobar un flujo completo

deberia haber:

  • 0-1% unit, solo tests que sirven de documentación de cosas muy jodidas de entender de la logica
  • 99% integracion, acceptance, toda la integracion, DEBE ser ACCEPTANCE cambiando el ENV=local to ENV=DEV/PRE/PRO
  • 1% e2e para edge cases de networking, documentar bugs y breaking changes por ejemplo
PaCoX

TEP mejor que nada

B

fuzz testing, sin duda...

1 respuesta
Kaledros

Es que para cosas como validar el input de un endpoint (los valores del body, los headers, etc) no necesitas levantar toda la mandanga para hacer tests de integración, puedes testearlo de forma unitaria y en paz. Y como eso muchas cosas. Obviamente, si vas a meter un test unitario para comprobar que un repository devuelve bien lo que le llega de DB eres mongolo, para eso sí necesitas integrar.

1 1 respuesta
desu

#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.

1 1 respuesta
B

En el momento que pruebas sistemas externos ya haces test de integración... y si tienes que hacerte un Mock da igual como lo llames, porque querra decir que el servicio contra el que atacas no está ofreciendo un endpoint de testing.

1 respuesta
desu

#57106 Si usas un mock es que estas en local, cuando pasas a dev/qa/pre/pro debes usar el sistema real corriendo en ese entorno.

La unica diferencia entre un test de INTEGRACION bien escrito, y un test de ACCEPTANCE o FUNCIONAL corriendo en pro es que has cambiado la variable de entorno de ENV=local a ENV=pro.

Luego el flujo de CI de local => a merge a master lo puedes montar de varias maneras. Existen 2-3 estrategias que son comunes y mas o menos igual de validas, cada una tiene sus pros/cons.

Tu puedes tener:

uso el mock en la Pull request, si pasa, merge a master. Cuando hago merge a master hago deploy a dev/pre/pro... y ahi hago re-run de los test de integration(acceptance). Puede ser que ESTO FALLE y tenga que hacer re-roll.

uso el mock en la PULL request, si pasa, hago deploy a DEV, si pasa en DEV. Hago merge a master... El problema de esto es que puedes tener entornos de DEV rotos o si mucha gente trabaja en el mismo servicio, te puedes pisar la PR. Necesitas tener tagging y demas estrategias para granularizar tus tests.

no entrare en mas ejemplos, os los imagináis, para mi el primero es lo mejor para la gran mayoria de productos, 99%. la responsabilidad des del ingeniero garantizar y monitorizar el deployment cuando haga merge a master por si hay que hacer re-roll. ese es el CON.

Kaledros
#57105desu:

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

Pero no necesito un test de integración para testear la lógica de validación, que es a donde voy. Para eso sólo tengo que testear el código, no todo el flujo.

2 1 respuesta
desu

#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.

1 respuesta
Kaledros
#57109desu:

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

Pero es que tú no programas en el vacío, si cambias algo que rompe un contrato puede ser por dos motivos:

  • Eres la fuente de la verdad. Enhorabuena, has roto todas las integraciones y tendrían que echarte por mongolo.
  • Has cambiado por tu cuenta y riesgo un contrato siendo el cliente y has roto la integración con la fuente de la verdad, tendrían que echarte por mongolo.

Cuando metes un breaking change en un contrato lo suyo es a) avisar, b) subir de versión y no tocar la anterior y que quien quiera que vaya integrando la nueva versión y haciendo sus pruebas contra tu contrato.

1 respuesta
eondev

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

1 respuesta
desu

#57110 mira puedes re leer mis mensajes

en los tuyos dejas claro que hablas de cosas muy muy simples

cuando tienes cien equipos y miles de servicios la manera correcta de trabajar es la que explico fin

si crees que porque tienes algo trivial y básico puedes hacer malas prácticas allá tú. todo tiene sus pros y cons.

si te crees que en una empresa con diez mil empleados se puede avisar de algo que afecta a otro… está claro que tu caso es trivial y simplísimo

Sobretodo cuando no sabes quien está usando tu producto por ejemplo

Y no estoy queriendo sonar agresivo ni troll en este mensaje. Cuando hayas tocado algo súper complejo y difícil entenderás al pie de la letra lo que digo.

aren-pulid0

#57111 cuéntanos más, le hiciste pen testing?

Zh3RoX
1 respuesta
r2d2rigo

#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.

1 respuesta
Wei-Yu

#57115 el otro día me mandaron este email:

Thank you for the interest in our open position ********. We received 233 applications in 48 hours, LinkedIn screening reduced this number to 33 good matches and after our manual review we are left with 10 promising candidates. But we can only hire one so I am reaching out to you to ask a few more questions.

para que veas el ratio

1 respuesta
r2d2rigo

#57116 ha sido mi experiencia tambien en las pocas ofertas que he echado por los loles, en casi ninguna me han dicho que no.

Menuda burbuja de bootcampers tieneq ue haber.

GaN2

A alguno le va a dar un infarto cuanto se entere que nosotros tenemos que tener unit test para probar el código que se sube al repositorio durante la PR y que si no se valida durante el presubmit por muy fuerte que hagas click en el botón no va a pasar a la siguiente fase. Y así con todas las FAANG y similares pero que sabrán ellos…

1 2 respuestas
Kaledros

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

2 respuestas
HeXaN

#57119 Same here.