Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




wdaoajw

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

desu

#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

#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

el opensource es el dimonio

3
Wei-Yu

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

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

desu

#35075 porque no es unitario?

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

1 respuesta
Kaledros

Wei-Yu

#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

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

desu

#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

#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

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

#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

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

1 respuesta
desu

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

#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

#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

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

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

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

#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

#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

#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

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

#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

go, elixir o rust xd

2
desu

#35098 4 fun o para que?

4work:
Go
Rust

4fun:
Elixir
Ocaml
Nim

3 respuestas