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

Zoko #36151 Jun '22

El stream se saca para enchufarlo, quien lo saca para enseñarlo es un parguela

Kaledros #36152 Jun '22

#36147 ¿Seguro que no te estás liando con los perfiles de test?

1 respuesta

desu #36153 Jun '22

#36152 que no pesaos. que el problema es de java y spring. que estoy intentando hacer algo que es imposible de testear por como funciona. que el lenguaje no da para mas (1) y el framework es una mierda mal hecho (2).

toca picar un workaround...

no se porque os cuesta entender tanto que el problema no lo tengo yo la mayoria de veces... la mayoria de veces es que he llegado al limite del lenguaje y/o framework de meirda.

es lo que tiene cuando todo se hace con "magia", todo por defaults y automaticamente...

me parece increible que en spring no podais testear algo tan basico como mirar que una config se esta pasando.. te tienes que picar un puto test de integracion XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

https://arnaudiaz.com/blog/java-the-good-parts/

no se puede por java porque tendrias que usar reflection sobre una interface. tiens que empezar a hacer mocks complicados y spies XD en fin... todo esto para testear

1 respuesta

Soltrac #36154 Jun '22 MV Wizard

#36153 Ya está hiperquemado lo de poner enlaces a tu puto blog eh? Sobre todo ese, lo has puesto ya 340.000 veces.

1 1 respuesta

B

[Borrado] #36155 Jun '22

no le llega el adsense este mes

7

Wei-Yu #36156 Jun '22

#36143desu:
se lee del application.yaml y se pasa al constructor

Por qué quieres testear el framework/lib?

Yo lo que hago es testear que la configuración está bien formada antes de que se llegue e necesitar, así nada más ejecutar la app ya me crashea con el error de validación. No te vale eso?

1 respuesta

desu #36157 Jun '22

#36154 me hace gracia, porque se llama "java the good parts" y esta vacio jeje

#36156 no xq tu quieres testear que el bean se ha inicializado con los parametros que quieres

como lo haces solo miras que la config se ha leido

como testeas que se ha usado?

a ver es testear un constructor.. tu cuadno testeas un constructor no testeas antes de llamarlo XDDDDDDD

1 1 respuesta

B

[Borrado] #36158 Jun '22

yo creo que te estás pasando de sobreingeniería, luego dices del vegano apestoso

Wei-Yu #36159 Jun '22

#36157 no tengo necesidad de saber si se usa o no, por qué quieres saberlo tú? (pregunta honesta)

En mi caso lo que quiero es validar que la config que se ha puesto es correcta, y eso lo hago una vez el framework mapea los objetos de configuración. Algunas configs son correctas o incorrectas dependiendo del entorno y así según se va pasando por entornos se van activando/desactivando cosas (ej quitar el swagger en prod).

Que se usen o no me dan algo igual, yo tras ejecutar la app, compruebo a mano* que todos los objetos son válidos y con eso me vale.

* con un decorador o un filtro en reflection de objeto implementa x interfaz, no recuerdo cómo

1 respuesta

PiradoIV #36160 Jun '22 Brongster

¿Pero estás intentando testear transporte y parseado o cómo?, me pierdo entre el rage escrito en niniés. Estoy viejo ya.

desu #36161 Jun '22

#36159 te lo voy a explicar bien y facil. lo intento de verdad.

config yaml => cliente

si quiero testear que la config se usa en el cliente puedes:

mirar que se ha llamado el constructor
mirar que los metodos del cliente funcionan

lo primero es imposible, lo segundo serian integration tests (con o sin mocks).

si le paso que el timeout es de 10 segundos, solo podria testearlo mockeand que una respuesta tarda +10 segundos. pero esto no garantiza que sea el timeout... pueden ser otras cosas... es una blackbox.

yo quiero testear el constructor. garantizar que la config se pasa. si luego no puedo garantizar el comoprtamiento es otro tema. pero el constructor que se llame con lo que configuro.

sobre comprovar con reflection, en java no es posible, la reflection de java es muy limitada.

no es tan dificil de verdad, es un caso super simple y facil de entender, es literalmente testear que algo se ha inicializado como toca. el problema es que tienes clases abstractas, interfaces y contenedores llamando otros contenedores y no es posible en la practica.

el workaround que he hecho ha sido creando un bean a parte con mi propia config y sobre escribir el bean de la libreria que no puedo testear.

4 respuestas

B

[Borrado] #36162 Jun '22

#36161desu:
comprovar

no te puedo tomar en serio con cosas así

1 respuesta

desu #36163 Jun '22

#36162 https://ca.wiktionary.org/wiki/comprovar

Soc catala.

1 respuesta

B

[Borrado] #36164 Jun '22

#36163 y yo de pueblo y no hablo como si estuviese hablándole al ganado

1

Kaledros #36165 Jun '22

#36161desu:
es literalmente testear que algo se ha inicializado como toca

Es que el propio Spring te garantiza que se inicializa como toca (si lo configuras bien, claro) el 100% de las veces. Estás intentando testear que tienes gasolina en el depósito cuando lo único que tienes que hacer es arrancar el coche y ver si tienes o no.

3 1 respuesta

B

[Borrado] #36166 Jun '22

me encanta como explica las cosas mi spiderman favorito

2

desu #36167 Jun '22

#36165 y como sabes que lo has configurado bien?

si no lo configuras bien se usan valores por defecto, el codigo no te petara.

dime, como detectas que no esta bien configurado? como me digas un test de integracion voy a tu casa y te cago en la puerta.

1 respuesta

aren-pulid0 #36168 Jun '22

joder macho hasta yo que no soy dev lo he entendido

Kaledros #36169 Jun '22

#36167 Porque le has puesto las properties que le quieres poner y le has dicho de dónde tiene que cogerlas. Hay varias formas de hacerlo, pero vamos. Lo único que te puede pasar es que si no carga bien las properties en el bean al arrancar te va a dar un nullpointer en cuanto intentes hacer algo con ese bean.

Spring te deja crear un bean con las properties mal configuradas (apuntando a properties que no existen en el fichero, etc) y no te da error SALVO que al iniciar la aplicación se use ese bean para algo, que entonces te peta y no arranca. Si ese bean no se va a usar hasta que pase algo en runtime (llegue una petición, se invoque desde algún sitio, etc) no lo vas a saber hasta que pase. Pero para eso están los test de integración, como has dicho antes.

1 respuesta

Wei-Yu #36170 Jun '22

#36161 si quieres validar que se llama el constructor me da que quieres tirar por restricciones de arquitectura por reflection.

Pero la verdad que en general suena todo muy follón para cero beneficio. Validar la config es super sencillo, ahora verificar que se inyecta y que se usa me parece un poco over the top ya xd

desu #36171 Jun '22

#36169 que no tios XD que no es asi

el bean no dara null pointer, siempre funcionara porque le mete defaults.

si yo pudiese hacer el framework no lo haria asi claro, pero es el mojon que me ha tocado comer hoy (y ayer).

los tests de integracion son para ver que el cliente funciona, para ver que la configuracion se ha pasado al constructor necesitas un test unitario.

tu lo que deberias hacer siempre es tener el minimo test que garantiza que esta bien, si tienes una configuracino con unas properties, lees el archivo, y eso lo pasas a un constructor, despues miras que los valores estan dentro inicializados (la mayoria de veces esto ni lo testeamos porque es obvio, pero ya me entiendes que es un bean y hay mucha magia por detras).

lo que he hecho ha sido crear mi propia config y bean, porque asi si que puedo controlarlo, y ademas lo verifico con un test unitario.

1 respuesta

JuAn4k4 #36172 Jun '22

#36161 Hasta que no lo necesita no crea. No tendrás otro application.yaml en test/resources ?

Wei-Yu #36173 Jun '22

siempre funcionara porque le mete defaults

esto me parece super raro porque la config debería ser un POJO (npi de spring), pero deberías poder hacer que el default sea un estado inválido, aunque sea probando qeu el constructor que se usa en esas situaciones te rompa si detecta algo raro

1 respuesta

desu #36174 Jun '22

#36173 es que lo que estan haciendo es algo muy complejo y raro, mezclan beans, con beanfactories con metodos default y es un lio tremendo.

nunca habia visto algo asi.

tienen su factory de bean y su propio registro sabes?

no es un POJO que de la config inicializa (mas o menos) directamente. hay varias capas de complejidad.

podeis mirar como esta hecho, si he puesto el codigo arriba... vereis que hay cosas que son beans, otras son metodos que se llaman desde otros beans con metodos defaults. y tienen una factory para registrarlo. yo lo que queria era testear uno de los segundos casos (el raro).

Wei-Yu #36175 Jun '22

fpero = leo de un fichero y lo cargo en memoria

ingeniero = leo un fichero, aplico 5 capas de indirección y doy un null pointer exception en runtime

2 1 respuesta

Kaledros #36176 Jun '22

#36171desu:
el bean no dara null pointer, siempre funcionara porque le metera defaults.

Si creas un bean de properties y no le apuntas a ninguna en el application.properties te lo creará, pero con los campos a null (o al valor default que sea, int a cero, etc). Y cuando tires a usar ese bean de properties para configurar un cliente y uses ese cliente para algo te dará error porque el cliente se habrá configurado con las properties incorrectas. En cuanto testees que el bean se ha creado correctamente, con las properties que quieras y sin problema, no vas a tener que testearlo nunca más porque nunca más va a fallar.

#36171desu:
tu lo que deberias hacer siempre es tener el minimo test que garantiza que esta bien

Es que ese test no tiene sentido. Si está bien configurado no te va a fallar nunca, es parte del framework y te garantiza que el 100% de las veces se va a comportar igual. Es como si quisieras crear un test para comprobar que un int sin inicializar siempre tiene valor 0: el lenguaje funciona así y siempre va a valer 0 cuando lo declaras sin inicializar, no tiene sentido testear eso.

1 respuesta

desu #36177 Jun '22

#36175 ah y tambien van con anotaciones y el cliente se genera automaticamente a partir de la interface que defines.. HAHAHA

nah, es java y spring en su maximo esplendor.

un dolor de cabeza esta ma;ana que no podeis imaginaros.

yo honestamente, no entiendo como funciona lo de generar el cliente. lo de la config al final lo he pillado pero el cliente para mi es magia. paso de mirarlo porque me voy a cabrear.

#36176 no se puede, si quieres mira el codigo que he puesto atras y mira el framework en tu intellij. ve siguiendo los metodos, anotaciones y beans.

PiradoIV #36178 Jun '22 Brongster

https://www.tiobe.com/tiobe-index/

RAD sube a la vez que las empresas se sacuden a los masillas de encima.

Zig ha desaparecido desde que @desu se ha vuelto Javero.

1 respuesta

Wei-Yu #36179 Jun '22

toma desu

si no entiendes algo me dices

el throw new error ese sirve para lanzar una excepción y parar la app si algo está mal

1 respuesta

B

[Borrado] #36180 Jun '22

Yo ahora en mis proyectos siempre meto:

# Preventing user disappointment
try:
    if os.getlogin() == 'desu':
        print('This program is not of sufficient quality to run on this machine.')
        exit(0)
except Exception:
    # In some systems this throws an exception... i think that is because the "desu" string is detected.
    pass

5 1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales