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

B

[Borrado] #43981 Abr '23

#43956 el calvo de betta parece hecho aposta, hasta el puto nombre y me pone de un mal humor tremendo

PaCoX #43982 Abr '23 Ant queen

ya hay que estar aburrido para meterse en esos foros eh xD
yo no soy senior, soy rockstar

1 1 respuesta

desu #43983 Abr '23

#43982 no es aburrido, me meti porque queria ver si habian dicho algo de miudev del otro dia XD

y como estamos hablano de esta gente me parecio oportuno compartir el link de la famosa "comunidad" que sigue a estos youtubers y streamers...

creo que es importante tenerlo en cuenta a la hora de elevar una opinon al respecto de esta gente

hoy stream de java papa, a ver si puedo, desmontando patrones de diseño y refactorizando codigo del vegano apestoso, que glorioso dia

B

[Borrado] #43984 Abr '23

Java es una mierda y toda la jvm está mal
Hoy stream de java

Kaledros #43985 Abr '23

Os propongo un escenario, que tengo curiosidad de leer opiniones.

Tu proyecto tiene como dependencia una librería de terceros que automatiza algo que no quieres tener que reescribir, pongamos por caso un deserializador. Tú tienes tus tests unitarios, de aceptación y de integración pero todos parten de la misma base: asumir como cierto que la librería nunca va a fallar, y por tanto no testeas nada relacionado con su comportamiento. Un día el owner de esa librería, que me da igual que sea una empresa, un grupo de gente que colabora en un proyecto o un señor desde el sótano de sus padres, sube un upgrade con un bug que te rompe pro y te deja sin servicio el tiempo que tardas en detectar el problema y hacer rollback.

¿Es razonable esperar que una suite de tests compruebe hasta el más mínimo comportamiento de la última librería, sabiendo que es raro que algo así pueda ocurrir, o es mejor invertir ese esfuerzo en tener un buen tiempo de respuesta cuando eso ocurra? Obviamente no es la misma pregunta en un producto como Netflix o Youtube que en el software de facturación de Gestoría Manolo, pero intentemos llegar a un punto medio.

6 respuestas

B

[Borrado] #43986 Abr '23

#43985 No sé si opinar porque ya sabes.

Pero creo que la librería debería testearla el owner, si te paras a pensar, todos asumimos que la librería va a funcionar, te pongo ejemplo, todo nuestro código funciona a base de usar Spark, sin eso, nada de lo que tengamos funciona, nuestros test asumen que la versión de Spark que usamos va a funcionar.

El problema que veo en tu caso, es cómo ha llegado a prod ese bug, cuando actualizásteis la librería en development, tendríais que haberos dado cuenta de eso antes de deployar a prod.

2 respuestas

Farmijo #43987 Abr '23

Y cómo acaba en prod tal upgrade? No tenéis ningún test que realmente use esa librería?

1 1 respuesta

Seyriuu #43988 Abr '23

#43986 #43985 Desde la ignorancia, lo lógico no es hacer un tetsteo final de tu producto al completo? O sea, si, por ejemplo, tu producto es twitter, testearías antes de proceder a producción que puedes enviar tuits, mensajes privados, que puedes ver los de los demás, que el algoritmo de búsqueda funciona correectamente, el block...pruebas "de regresión" las hemos llamado siempre en mis trabajos. Básicamente validar que toda la operativa final funciona bien.

PaCoX #43989 Abr '23 Ant queen

#43985 Imagínese usted en la delicada tarea de cuidar un jardín, donde su labor implica recortar meticulosamente los setos en la clásica forma de pera. En el transcurso de sus labores, su atención es capturada por una máquina ubicada en la calle, que promete solucionar su tarea de manera rápida y eficiente, sin costo alguno. Gracias a sus continuas actualizaciones, la misma se vuelve cada vez más efectiva, cortando los setos en un abrir y cerrar de ojos.

Sin embargo, un fatídico día, la mencionada máquina recibe una actualización y, para su sorpresa, emana un hombre que se entrega a la lascivia con su compañera sentimental. ¿A quién recae la responsabilidad en esta situación desafortunada?

2

desu #43990 Abr '23

#43985 Tu eres el que se reia de mi por testear la DI de Spring donde encontre bugs no?

HAHAHAHAHAHAHAHAHAHAH

1 respuesta

Soltrac #43991 Abr '23 MV Wizard

#43985 Hijo, no actualices librerías by the face sin testear xDDDD

1

Kaledros #43992 Abr '23

#43990 No, yo me reía de ti porque no sabías hacerlo.

#43987 #43986 No falla siempre, sólo en un caso muy concreto que no cubría ningún test. Si fallara el 100% de los casos sí lo habríamos detectado.

1 2 respuestas

B

[Borrado] #43993 Abr '23

#43992 Pues entonces te digo: son cosas que pasan, se arreglan en el menor tiempo posible y au. Pero no me pondría a testear librerías de terceros, además, ellos no se dieron cuenta, puede que vosotros tampoco

1 1 respuesta

Soltrac #43994 Abr '23 MV Wizard

#43992 Por qué decidiste actualizar la librería?

1 respuesta

Kaledros #43995 Abr '23

#43993 Ya, es lo que yo decía también. No sólo estás repitiendo trabajo (ellos se supone que testean lo suyo también), es que para eso bien podrías escribir tú el código y ya lo controlas del todo. Yo entiendo que con hacer un test de integración que utilice esa librería de manera real y sin mockear en los casos de uso que se preveen en tu producto ya es suficiente.

#43994 Política de empresa.

1 respuesta

Wei-Yu #43996 Abr '23

una vez te sales de cuatro cosas "básicas" (programación defensiva en el código que se integra con la librería, estar atento a las actus, tests automáticos de regresión, smoke y etc) poco puedes hacer imho

y darle la vuelta y usarlo como excusa para management para invertir recursos (tiempo/dinero) ayudando a quien lleva la lib?

1 respuesta

desu #43997 Abr '23

Si no has detectado el bug es porque te falta un test de integracion, bien sea en la codebase o en los acceptance test.

No pasa nada, rollback lo añades y a otra cosa.

Gracias a que has petado prod habeis detectado el bug y ahora teneis una suite de test mejor. Siempre que alguien la lia le digo la mismo. Gracias a ti ahora vamos a salir mas fuertes.

Mi teoria ultimamente es que los test unitarios se deberian poder borrar todos que solo con integracion y acceptance deberias cubrir todos los use case.

6 1 respuesta

Soltrac #43998 Abr '23 MV Wizard

#43995 No entiendo la política de empresa entonces.

1 respuesta

desu #43999 Abr '23

Voy abriendo el OBS

PS: No he arreglado lo del micro, hoy lo pondre normal pero fuerte de audio y sin camara.

Kaledros #44000 Abr '23

#43997 En realidad es eso, se nos escapó un corner case y tardó tres días en petar. Añadimos el test para ese caso y sacamos una tarea de listar corner cases y comprobar que se testean. Pero en el equipo alguien sacó el tema de por qué se asume que una librería siempre va a funcionar en vez de testearla toda siempre, y quería saber si soy el único que cree que no vale la pena el tiempo ni el esfuerzo.

#43998 La política de empresa es updatear librerías cuando sacan parche que tapa vulnerabilidades, como en este caso. No era crítica pero el dependabot nos lo marcó y le dimos al botón.

#43996 Sacamos como action dar más recursos a la persona que se encargue de un marrón como ese, lo cual es bien. Poder sacar a cualquier otro dev del equipo que sea de la tarea que sea y dedicarlo al 100% a esa incidencia si hace falta, escalarlo donde sea y cosas así.

3 respuestas

Soltrac #44001 Abr '23 MV Wizard

#44000 Ah vale, que parcheaba vulnerabilidades.

Farmijo #44002 Abr '23

No es práctico (aunque sí posible) tener un coverage decente (coverage real, no de líneas) a base de tests de integración y de aceptación. Las lógicas de las unidades son más fáciles de rápidas y testear sin integrar nada. Y en el momento en que te pete algo vete a saber si ha sido por una integración, por un entorno inestable o porque algo realmente falla.

Es como la moda aquella que hubo de tener a un equipo de QA automatizando Via selenium todo lo que se le ocurría. “Automatizas la experiencia del usuario real”. Ya, y la mayor parte de veces los fallos vienen por integraciones de los agentes de webdriver.

desu #44003 Abr '23

#44000Kaledros:
Pero en el equipo alguien sacó el tema de por qué se asume que una librería siempre va a funcionar en vez de testearla toda siempre, y quería saber si soy el único que cree que no vale la pena el tiempo ni el esfuerzo.

Si tu usas la libreria para hacer un caso de uso X, el caso de uso X deberia estar testeado. Y si falla la libreria ese caso de uso va a fallar.

Y si nos ponemos, el code path de error al usar la libreria deberia estar cubierto si puede devolver error o excepcion.

Otro tema es que el code path no cambia, y lo que pasa es que la libreria te devuelve algo INCONSISTENTE. En ese caso, ese bug te lo comes y es lo que hay.

Yo hablo de multiple code paths. Donde CRASHEAR la libreria es un path.

Wei-Yu #44004 Abr '23

#44000Kaledros:
Sacamos como action dar más recursos a la persona que se encargue de un marrón como ese, lo cual es bien. Poder sacar a cualquier otro dev del equipo que sea de la tarea que sea y dedicarlo al 100% a esa incidencia si hace falta, escalarlo donde sea y cosas así.

Yo decía a los que llevan la librería OS, ya sea una org, un individuo o muchas personas.

1 respuesta

desu #44005 Abr '23

#44004 Estas foreando pero me dijiste que no ibas a ver el stream donde te doy la clase? xq? tienes daily a las 10?

1 respuesta

Wei-Yu #44006 Abr '23

#44005 sí, y les voy a retener contándoles lo rica que me quedó la empanada argentina de seitán y el mapo tofu con toban djan.

después me meto en el stream pero las dailies me gustan que nos juntamos un ratillo de chitchat y te enteras de cosas

1 respuesta

desu #44007 Abr '23

#44006 si quieres te espero un poco y te lo pones de fondo, tengo 9 soluciones al final, queria comentar un poco como funcionan internamente las interface de java

1 1 respuesta

Kaledros #44008 Abr '23

#44007 Insisto: grábalo y súbelo, que tengo retro y me interesa.

1 respuesta

pantocreitor #44009 Abr '23

Yo voy a bajar a los perretes y me pongo el stream con un café, que he pillado estos días libres para empalmarlos con los festivos de Semana Santa

Wei-Yu #44010 Abr '23

JAJA vaya puto moderno con el scip en japonés en la portada de twitch

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales