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

wdaoajw #35071 May '22

#35070 en realidad lo único que me jode es no poder cebarme a horchata

desu #35072 May '22

#35069 si vas a alguna conf avisa y me apunto, yo tengo un par de ks de presupuesto.

a la que quiero ir es a la de aws en las vegas.

B

[Borrado] #35073 May '22

#35070 qué tal todo? hace meses que no nos visitas ¿te has pasado ya a algún ide de este siglo tipo IntelliJ o algo así?

PaCoX #35074 May '22 Ant queen

el opensource es el dimonio

3

Wei-Yu #35075 May '22

me echa un cable con el proyecto un dev de otro equipo y veo en la PR que me mete un test "unitario" que se conecta a un service bus y que tiene el secreto hardcodeado en la config de los tests

2 2 respuestas

r2d2rigo #35076 May '22 Inocente

#35075 hora de apuntarte el secret y usarlo para farmear bitcoins desde casa gratis.

desu #35077 May '22

#35075 porque no es unitario?

a ver si te tengo que dar una master class en testing.

1 respuesta

Kaledros #35078 May '22

Wei-Yu #35079 May '22

#35077 venga, muerdo el bait. Por qué una conexión http dentro de la ejecución del test no rompe la definición de test unitario?

1 respuesta

Soltrac #35080 May '22 MV Wizard

Estoy expectante a la respuesta de desu. Luego doy mi opinión.

desu #35081 May '22

#35079 no se que definicion tienes.

si esa funcion solo ejectuaba ese codigo esta perfecta.

puedes tener un mock de la conexion y luego el test de integracion con algo real. depende de si testeas la ejecucion o la integracion con el servicio o la implementacion de tu logica sobre el servicio.

te lo he dicho porque me he dado cuenta que en java world y c# donde tu vienes, la gente hace tests que no valen para nada. o hace test de integracion enormes al final de todo. noooo.

lo bueno de tener el test unitario de esa conexion lo mas peque;o posible es que puedes construir encima de el sin tener que volver a estear el servicio real.

1 respuesta

Soltrac #35082 May '22 MV Wizard

#35081 No tiene mock, te ha dicho que ha puesto el secret. Responde si está bien o mal, no le des más vueltas xD.

Pero bueno, doy mi opinión. Depende de lo que esté testeando (y entiendo que no es la conexión), lo correcto es hacer un mock de la conexión y simular las respuestas. Habría que ver ese service bus hasta q punto es mockeable o si el tío ha sido vago y listo.

2 2 respuestas

Wei-Yu #35083 May '22

te lo he dicho porque me he dado cuenta que en java world y c# donde tu vienes, la gente hace tests que no valen para nada.

100% agree tbh

desu #35084 May '22

#35082 lo del secret obvio que esta mal.

yo le estoy respondiendo a llamar test unitario a algo que integra un servicio. esta bien. unitario y de integracion al mismo tiempo. unitario es que testeas 1 unidad de algo. funcion/servicio/modulo. da igual.

de hecho siempre deberias hacer los test de integracion en la capa mas peque;a y en el servicio / dependencia mas aislado posible. de esta manera puedes construir sin tenerque volver a testear nada.

1 respuesta

PaCoX #35085 May '22 Ant queen

test unitarios y de integración, otro mal de la industria. Waste of timeee

1 respuesta

desu #35086 May '22

#35085 literalmetne hoy he tenido una charla sobre este tema de 1h conun compa;ero XDDD

los tests de integracion, si no se acaban ejecutando sobre un servicio real no valen para nada.

da igual que sea un test peque;o que se coenxta a un bus o hace una llamada http o es un test de integracion de toda tu app y lo llamas acceptance test. da igual. es una mierda que no vale para nada.

CODE COVERAGE != CODE QUALITY o TEST QUALITY

desu #35087 May '22

#35082Soltrac:
lo correcto es hacer un mock de la conexión y simular las respuestas.

si testeas la API de tu funcion/servicio si.

si quieres testear la integracion no.

si puedes testear esa integracion en un test unitario de una funcion, es mejor que hacerlo a nivel de servicio donde tienes varias capas de abstraccion.

lo CORRECTO es tener AMBOS TESTS.

Wei-Yu #35088 May '22

#35084 integración y unitarios son dos layers distintas, no puedes mezclar el step de unitarios con el de integración en el CI, ni tampoco puedes ""extender"" los unitarios para hacerlos de integración

un unitario debería testear una función sin side effects, que en c# se traduce como testear 3 clases y 20 métodos privados

1 respuesta

desu #35089 May '22

#35088 no. son dos layers distintas. eso es una idea que invento uncle bob o el gilipollas de flowers, que bien se las podria meter por el culo.

cuando querais os ense;o a testear bien, lo digo en serio. y vereis como tengo razon y escribereis menos codigo (tests duplicados) y ademas vuestro feedback loop sera menor.

un unitario debería testear una función sin side effects,

de nuevo, mezclais el tipo de test con su intencion.

tengo una talk sobre este tema que di hace poco.

Kaledros #35090 May '22

Nosotros usábamos tres capas de test:

Unitarios. Todo mockeado, se testea una funcionalidad concreta pero nada sale ni entra del exterior.
Integración con mock: si tenemos la especificación de la API se usa un mock (Json Server, Localstack, etc) para mockear el resultado.
Integración: se testea contra el servicio/API real.

1 1 respuesta

desu #35091 May '22

no tengo puesto funcion o metodo o clase, pero estaria dentro del modulo.

lo unico que importa es la public API, los boundaries en lenguaje DDD y la integracion.

cada capa debes tener la API i la integracion
si yo testeo algo en una capa inferior, no hace falta hacerlo en una superior

el vocabulario de test se lo invento uncle bob y el otro soplanuncas, tansolo pensad en QUE, COMO, CUANDo, DONDE y PORQUE testeais codigo.

el como si usas mock o no, da igual en que capa estes.
el donde, pues en local o en pre o en produccion
el como, pues usando una travis build, haciendo un A/B en otro cluster, en local haciendo mvn test...

si tu haces un test a nivel de modulo perfecto, 100% coverage + 100% mutate state + 100% integracion. ese codigo, no necesitas volver a testearlo con integracion en una capa superior. puedes mockearlo.

la gente se piensa que cuanto mas arriba en la capa de la cebolla mas integracion y mas e2e.. estan mezclando ideas. seguramente alguien les ha vendido un libro o un coaching.

en fin, que asi se ha testeado toda la vida. lo que en java, python y similares lo haceis mal porque sois gilipollas y no usais el cerebro.

por ejemplo, para testear la app final o user, e2e, no hace falta mockear nada. siempre llamadas reales.
en la capa de controllers, seguramente solo hacen falta mocks.
en la capa de servicios, mocks + integracion.
en la capa module y unitarios mas peque;os, mocks + integracion.

#35090 esto esta bien si lo haces para cada capa que he puesto arriba.

la gente solo hace esto segun en que capa esta, hay que hacerlo idealmente en todo. y asi habra tests de integracion con servicios reales que no hacen falta...

esto es como un arbol, si has tacahdo la integracion de un servicio por abajo, a;adirlo arriba no aporta nada. de esta manera siempre puedes confiar en tus tests.

1 respuesta

Wei-Yu #35092 May '22

lo de función y 3 clases era por meterme con la gente de c#

si yo testeo algo en una capa inferior, no hace falta hacerlo en una superior

discrepo tb en esto, pero como todo hablar por hablar sirve de poco; es circunstancial

edit: la virgen cuánto edit

1 respuesta

desu #35093 May '22

#35092 esto esta demostrado matematicamente como quien dice. XD @fyn4r te hace la logica facil al toque...

si no puedes hacerlo, que te creo eh, es porque no estas aplicando la metodologia que te he dicho y te faltan cositas.

puedes discrepar de lo que quieras, pero 2 + 2 = 4. otra cosa es que no confies en tu equipo, que sois unos fperos y mejor testear para prevenir que curar... yo ahi no entro.

yo prefiero no testear cosas inutiles y ser metodico porque asi se que mi servicio siempre funcionara perfecto y tiene pocos tests.

pero vamos, te he explicado la teoria de verdad, lo que hay que hacer si no eres un fpero de mierda como tu lo eres. yo lo hago al toque. y no suelo necesitar mucho test. porque tengo toque.

recordad el QUE, COMO, CUANDO, DONDE Y PORQUE

solo hay que testear public APIs e integracion, y si quieres logica a nivel algoritmo tambien.
como con mocks o servicio real. usando travis, scripts, A/B con clusters...
cuando en la capa mas peque;a
donde local, pre o pro O

no tengo el vocabulario aun del todo bien hecho para el blog post, aun no he encontrado la manera perfecta de que la gente se acuerde y de definir. porque el como, cuando y donde se mezclan a veces. XD puedes tener una travis build para correr algo pre merge a master o para ejecutar unos tests en pre o pro...

el que y el porque son claros, hago test para ver si funciona la API, la integracion o la logica. Todo lo demas no hace falta. Es paja y sobre enginieria. Estas haciendo el desarrollo mas costoso.

Kaledros #35094 May '22

#35091 Nosotros lo hacíamos por módulo, microservicio y por servicio.

Si tienes un módulo que se dedica a gestionar productos en un marketplace se supone que tienes un servicio que los pone, otro que los modifica, otro que los quita, etc. Testeábamos la integridad del código (que no petara al recibir ciertos valores por parámetro, etc), la integridad del microservicio (mockeando las llamadas y las respuestas y metiendo casuística) y la del servicio (levantándolo todo y haciendo el test de integración real).

1 respuesta

desu #35095 May '22

#35094 esta bien, es lo que yo digo. pero yo estoy tratando de encontrar una formula o algo asi para explicarselo a los fperos. y tener un blog post.

Testeábamos la integridad del código (que no petara al recibir ciertos valores por parámetro, etc),

esto es testear la API de tu funcion por ejemplo... type driven design + DDD

es que siempre es lo mismo XD INPUT => XXXX => OUTPUT. Testear INPUT y OUTPUT es testear la API. Deberia ser siempre la PUBLIC API por cierto. Nunca hay que testear funciones privados, si lo haces hay que tener claro que se pueden borrar. testear cosas privadas solo es una metodologia de trabajo.

no se en que punto de la historia te aparecieron veganos

MTX_Anubis #35096 May '22 :psyduck:

Al final estáis discutiendo mayormente semántica.

Por cierto @desu, DDD debería hacerse siempre con type driven design (va implícito hacerlo así) otra cosa es lo que comenté el otro día, que se haga pura mierda se líen a aplicar patrones de todos los tipos en vez de pensar en el dominio y las invariantes. No sé por qué en FP se lleva mucho más hacerlo así que en OOP, debe de ser por el legado java.

1 respuesta

desu #35097 May '22

#35096MTX_Anubis:
Al final estáis discutiendo mayormente semántica.

no lo tengo claro, le digo al vegano, que el test unitario de integracion es el mejor test que existe.

mucha gente solo hace test de integracion en la capa mas a fuera posible, esto es lo contrario a lo que deberiamos hacer XD si ya has testeado una llamada http en una funcion, no hace falta testear esa misma llamada en el servicio... ni volver a hacerlo en el controller.

#35096MTX_Anubis:

DDD debería hacerse siempre con type driven design

bueno, es el tema de los limites del contexto y tal no?

hoy por ejemplo en una codebase he visto que teniamos unos DTO que re usabamos para el codigo de logica con metodos... que te cuesta tener el DTO para serializar facil y luego tener otro objeto si quieres para metodos? XD obviamente yo solo tendria el DTO sin metodos, tio que te cuesta escribir: foo(dto, params) vs dto.foo(params)? la gente es la polla XD

o me parseas el DTOX a EntityX o me usas funciones sobre el DTO. pero no me hagas dto.foo()

1 respuesta

MTX_Anubis #35098 May '22 :psyduck:

#35097 no, no es por el tema de los boundaries como tal (que deben definir un marco en el que un dominio es válido siempre) aunque sí que ayuda a identificarlos

Es porque tu modelado debe reflejar tu dominio y y su comportamiento de forma explícita y la única forma de hacerlo es mediate type driven design. El resto es esconder y ofuscar comportamiento y meter estructuras de control donde debería haber tipos nuevos.

Hablando de otras cosas, estoy buscando lenguajes que sean decentes y con bueno sistema de tipado y concurrencia de memomento me voy a poner con Pony que lo conocía pero no me puse con él (me he leído la documentación y la historia del creador, si te apetce echarle un vistazo al GC ) y Gleam (que lo he descubierto hace poco).

Tienes alguna sugerencia de algo que no sea zig? XD

1 respuesta

PaCoX #35099 May '22 Ant queen

go, elixir o rust xd

2

desu #35100 May '22

#35098 4 fun o para que?

4work:
Go
Rust

4fun:
Elixir
Ocaml
Nim

3 respuestas

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales