Feda /dev/ - No Javascript allowed | Página 1905

GaN2 #57121 12 Jul Inocente

#57119 mi comentario iba porque leyendo ciertos tochos parece que nadie en la industria usa unit test y solo lo hacen los fperos cuando no es así. Los unit test tienen su función así como los tienen otro tipo de test, usar de manera predefinida solamente una es absurdo. Entre otras cosas porque generalmente en arquitecturas complejas los unit test tardan segundos/minutos y los integration tests tardan minutos/horas. Es absurdo tener que esperar a que termine un test en integración para saber si el código que he subido tiene algún tipo de problema

4 2 respuestas

Wei-Yu #57122 12 Jul

#57121GaN2:
Entre otras cosas porque generalmente en arquitecturas complejas los unit test tardan segundos/minutos y los integration tests tardan minutos/horas.

Esto se puede interpretar como el problema del que habla desu. Que tampoco es nada nuevo, cuando empecé a estudiar por 2016-2017 recuerdo ya leer gente que parecía estar cagando fuera del tiesto con el mismo tema, y será una discusión que lleva dando vueltas décadas.

Yo creo que al final es algo que soluciona en parte la sobrehinjeniería de la hexagonal, con la capa de application services orquestando el dominio. Entiendo que así tienes margen para meter unitarios a cholón en el dominio al ser mayormente puro y la parte de application services puedes cubrirla con integration.

edit: con el primer párrafo a lo que me refiero explícitamente es a la queja típica de que los unitarios están acoplados estructuralmente al código, y al necesitar mocks a punta pala realmente no estás teniendo tests reales, por lo que son costosos de mantener y no aportan valor. En tu caso hablarás de otra cosa, pero hay mucha gente que omite este problema que digo y lo entiende como complejidad intrínseca a su solución, en vez de complejidad accidental.

1

D

desu #57123 12 Jul

#57118 puedes tener esos "unit test" siendo tests de "integracion locales", es decir usando "mocks".

si hubieses leído bien mis mensajes, y tuvieses un IQ superior a 75, te habrías dado cuenta que comentado varias veces que los tests de integración con ENV=local son importantes.

#57107desu:
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.

Hasta en este post he explicado esto concretamente. USO EL MOCK EN LA PULL REQUEST, tener integración tests con mocks > unit tests.

porque estos integraron tests, cuando esten en dev/pre/pro, solo cambia el ENV=$var, es decir, el CODIGO de test es EXACTAMENTE EL MISMO

1 respuesta

KarlosWins #57124 12 Jul

4

D

desu #57125 12 Jul

#57121GaN2:
nadie en la industria usa unit test y solo lo hacen los fperos cuando no es así.

para local se usan mocks auto-generados y tests de integracion locales, si quieres llamarlo UNIT TEST? ok, pero eso no es lo que el 99.999% de los fperos llama unit test.

#57121GaN2:
Entre otras cosas porque generalmente en arquitecturas complejas los unit test tardan segundos/minutos y los integration tests tardan minutos/horas.

Aqui es donde dejas claro que no tienes ni puta idea de lo que hablas tienes un IQ que apenas llega a 75, te cagas en los pañales Y no has leído lo que he explicado.

Los tests de integracion en entorno local deben ejecutarse en segundos y deben poder ejecutarse en el entorno local sin requerir maquinas o cosas raras. De nuevo me repito. Porque eres el TONTO DE LA CASE Y HACE FALTA REPETIRTeLO 10 VECES.
ENV=local/dev/pre/pro

#57121GaN2:
Es absurdo tener que esperar a que termine un test en integración para saber si el código que he subido tiene algún tipo de problema

Es absurdo tener que leer tus gilipolleces. Eres un mal programador para empezar, no tienes ni puta idea para seguir y para concluir no LEES NI RESPETAS al resto de compañeros cuando comentan y razonan las cosas educadamente como he hecho hoy yo.

Wei-Yu #57126 12 Jul

@gan2 no has tenido suficiente?! Quieres exponerte mas?! No aprendes la lección de los últimos dias.

Que juegas con las palabras muy gravemente y tan a la ligera, que mira por donde tu y este hilo ya habeis sido reportados telematicamente.

Los próximos 2 usuarios ya los tengo en la mira.

1 respuesta

GaN2 #57127 12 Jul Inocente

Kaledros #57128 12 Jul

#57123desu:
puedes tener esos "unit test" siendo tests de "integracion locales", es decir usando "mocks"

Entonces no ganas nada, realmente estás haciendo unit testing con pasos extra, levantando contenedores, brokers y demás infra.

2 1 respuesta

D

desu #57129 12 Jul

Y obviamente estoy hablando del caso ideal y perfecto, donde si tienes un equipo de 10 ingenieros, los 10 son ingenieros y no son fperos como vosotros.

En el mundo real, mi experiencia: hay unit tests que no valen para nada, los tests de integración solo cubren un 20% del código real, si eso, no se hace "integracion continua" entendiéndola como hacer re-trigger de master...

Pero por ejemplo, hablando en términos de controller/service/repository en un CRUD, en mi anterior equipo tenían tests unitarios en el controller, que sorpresa, eran exactamente igual que los de integracion... asi que tras un par de charletas como esta quitamos todos los tests unitarios de controller porque eran redundantes... aun asi seguimos teniendo tests unitarios para servicios y repositorios.

En un mundo ideal, si todo el mundo entendiese que los tests de integracion (sean locales, locales para CI pre-merge to master, o como acceptance en entornos de dev/pre/pro) son esenciales y mas importantes que el resto, no habria tests unitarios.

#57128 No duplicas codigo, solo tienes una (1) suite de tests de integracion, que se corren igual, ejecutan los mismos paths, code coverage, sean en env=local/dev/pre/pro. Esto es una puta maravilla... Que cojones hablas.

En un test unitario escribes un codigo que ejecuta un path, en otro test unitario otro... luego por otro lado tienes tests de integracion, que a saber que code coverage real tienen... por favor... que cojones hablais.

Paraos a pensar un poquito.

Si yo digo algo, y lo explico tan bien como lo estoy haciendo, es porque esta claro que lo tengo mas que estudiado, analizando, y hecho mil tests con distintos equipos de desarrollo y situaciones...

Sin entrar en que os doblo o triplico el IQ.

1 respuesta

Kaledros #57130 12 Jul

#57129desu:
tienes una (1) suite de tests de integracion, que se corren igual, ejecutan los mismos paths, code coverage, sean en env=local/dev/pre/pro

Coño, vale, te había entendido mal.

1 respuesta

GaN2 #57131 12 Jul Inocente

#57126 ojalá alguien me reportara tan fuerte como a @desu le reportan a HR por sus comentarios aquí

para concluir no LEES NI RESPETAS al resto de compañeros cuando comentan y razonan las cosas educadamente como he hecho hoy yo.

Lo triste de todo esto es que ahí fuera, en este mundo donde viven más de 6.000 millones de humanos, hay varias personas que te tienen que aguantar este tipo de gilipolleces todos los días.

D

desu #57132 12 Jul

#57130 Bueno, no pasa nada, al menos se nota que estabas leyendo.

Otros de tus compañeros tienen la neuronitas justitas para que sus ritmos vitales no confundan el hacer caca con comer.

1 respuesta

HeXaN #57133 12 Jul

¿Pero entonces qué le digo a mi CTO? Me estáis liando.

2 2 respuestas

Kaledros #57134 12 Jul

#57132 De todas formas estás obligado a pasar el mismo set varias veces apuntando a distintos entornos y eso no te quita que tus tests en local/dev pasen y peten en pre porque alguien ha cambiado algo. Es decir, sólo te evita testear lógica dos veces con dos tests diferentes (que ya es).

GaN2 #57135 12 Jul Inocente

#57133 que contrate a @desu, en dos meses dos declaran zona catastrófica y mandan a la UME para limpiar el vertido tóxico. Test no se si haréis pero subvenciones le van a caer unas cuantas

1 respuesta

B

[Borrado] #57136 12 Jul

#57133 Departamento de QA... vamos, en el pipeline un paso debe ser aceptado por este departamento para hacer deploy... y te arreglo dos problemas en uno. Que tu código sea probado como un usuario medio y solucionar el problema de paro en este país... ¿como te quedas?

D

desu #57137 12 Jul

#57135 Yo no trabajo con gente que no respeto

PhDfailer #57138 12 Jul

Imagina salir cansado del trabajo y ponerme a leer esos tochacos de lo mismo con lo que trabajo

9 1 respuesta

Farmijo #57139 12 Jul

Formas a parte, desu tiene bastante razon.
Al final los unit test puros solo valen para testear lógica de negocio de dominio pura, que en muchos casos suele ser simple y la complicación está en la orquestación de esas lógicas de negocio, si interactúas con un servicio externo o tienes que hacer llamadas a una DB o lo que sea en mitad de un flujo. Pero alguien se inventó en su día la cobertura por statements y por ramas y hay quien dio pie a que esos numeritos valen para algo.

Pasa que a los test de integración siempre se les ha considerado cómo integraciones reales con servicios externos reales, hablar de mocks ahí chirría un poco.
Pero es un tema de naming, con la filosofía creo que aquí todo el mundo está de acuerdo.

Luego hay otro dilema de los tests de controllers o listeners y la validación de payloads. Donde colocarla y donde testearla. Empujarla a capas de dominio, mantenerla a nivel de middleware en controller, probarla e2e o a nivel unitario extrayendo el validator a una función aparte (suelen ser lógicas que se pueden programar de forma pura…)

2 respuestas