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

Kaledros #44761 Abr '23

Y de todas formas puedes estar apuntando a su server de int validándote por secret key para los tests de integración, pero eso lo he visto poquísimas veces.

Lolerpopler #44762 Abr '23 Cinturón negro

#44747 Como ya dicen, si estas consumiendo una API de otra compañia, tu no tienes que testear nada y, no vas a querer hacer mas llamadas de las necesarias porque te van a cobrar/tendras una cuota, ademas de que los tests fallaran de vez en cuando porque una API no siempre va a ser estable (caida de servidor, timeouts, algun cambio que introduzcan que rompa algo...)

Como ya han dicho, mockear la request es lo ideal. Puedes hacerlo mirando su documentacion o usar una herramienta como vrcpy (en el caso de python) que hace la primera request y guarda la respuesta, cuando esa misma peticion se vuelve a ejecutar, en vez de usar la API te devuelve la respuesta anterior.

1

Dr_Manhattan #44763 Abr '23

Gracias #44759 es así.

Estaba optando por mockear, me parece mejor que testear la respuesta en vivo, solo quería saber cómo de mala idea es o si existe algún caso en que sea mejor hacerlo en vivo.

Gracias a todos por las respuestas.

Wei-Yu #44764 Abr '23

yo personalmente fuera de testear cosas específicas de infra (ej comportamiento con latencia o pérdida de paquetes en cliente) no mockearía un webserver http

la third party api debería tener un entorno de pruebas y ahí deberías poder hacer contract testing para asegurarte de que no se rompe nada con cambios nuevos

si no tiene entorno de pruebas ya es evaluar cuánto riesgo se quiere asumir a cambio de cuánto coste; siempre se puede tener un sistema de monitoreo con smoke tests de read paths (o una setup con datos concretos puestos sólo para hacer tests rw), pero si es algo importante y ni siquiera os ofrecen un entorno de pruebas la primera pregunta es por qué se escogió eso y si hay mejores alternativas, imho

2 respuestas

Dr_Manhattan #44765 Abr '23

#44764 estamos hablando de webscraping usando la propia api que usa la web para mostrar los datos. Simplemente quiero testear que un cambio en el código no rompe la estructura de datos que espero. Mockear la respuesta me soluciona la papeleta, siempre y cuando no me cambien la api

1 respuesta

Wei-Yu #44766 Abr '23

#44765 si es webscraping no estarías mockeando un punto muy probable de fallo? Hablo sin tener npi eh, pero entiendo que haciendo webscraping que te cambien un div de sitio es algo que va a ocurrir "bastante". No digo hacer uno u otro si no tener cubierta esta parte también.

1 respuesta

Kaledros #44767 Abr '23

#44764 Bueno, si el owner de la API tiene dos manos habrá versionado los endpoints, en cuyo caso un test que te pase no va a romperse nunca aunque lo hayas mockeado desde el principio. Si ni siquiera tiene versiones entonces sí, a tomar por culo.

1 respuesta

Wei-Yu #44768 Abr '23

#44767 aún versionando la api siempre está la variable humana que te puede romper el contrato (aka la gente de la otra empresa). No dejas de confiar en que la dependencia externa no haga nada raro, sólo que ahora crees más fervientemente porque en algún sitio pone v1.

Dr_Manhattan #44769 Abr '23

#44766 claro, pero es algo que no puedo controlar, lo que pretendo es: asumiendo que no me cambian nada y que siempre va a devolver lo mismo, quiero darme cuenta si meto la pata en el código

JuAn4k4 #44770 Abr '23

Más que testear su API, lo suyo sería que tu app sea resiliente a que esa API por lo que sea falle. Si falla mucho entonces os hace page y vosotros a ellos si fuera necesario, o simplemente una alerta para arreglarlo.
Test de contrato está bien para detectarlo tempranamente, pero las APIs externas (las internas también) fallan y van a fallar.

Es decir lo que tenéis que meter es chaos testing

1

Farmijo #44771 Abr '23

Creo que comenté en su día lo del campeón que había hecho el endpoint 500 veces más lento. Le convencimos para que lo dejase como estaba porque sus problemas de consistencia eventual no tenían porque afectar al resto de la empresa.

2 semanas despues, lo ha vuelto a dejar lento por exactamente el mismo motivo. Me cago en dios.

1 1 respuesta

JuAn4k4 #44772 Abr '23

Hoy hice un PR donde cree un value type, y me ha dicho el idiota que ya no aguanto que eso es llevar al extremo el single responsability. La madre que lo pario, dice que es más difícil de leer eso porque son 2 clases en lugar de tener lo mismo en 3 clases que ya existen y en los 3 tests que prueban eso mismo. Oye pues bien.

Camp1 #44773 Abr '23

Ya que ha salido el tema, qué usáis para tests de integración y/o contract tests.

En mi empresa se usa cucumber, pero el proyecto lo gestiona QA, está más enfocado a testar una web app que a testar integración de APIs. Si que hay una suite para algunas partes críticas pero no el coverage que nos gustaría. Si alguien mete un breaking change en un microservicio nos comemos con patata el bug.

1 respuesta

Farmijo #44774 Abr '23

Estoy en una reunión que es a su vez una preparación breve para otra reunión en la cual nos introducirán como harán un traspaso de conocimientos.

Me cago en mi puta vida.

Dr_Manhattan #44775 Abr '23

Hazte un blog

Un saludo.

1 respuesta

Farmijo #44776 Abr '23

#44775 Este hilo es para soltar chorradas

1 respuesta

Dr_Manhattan #44777 Abr '23

#44776 te lo has tomado al pie de la letra

1 respuesta

Farmijo #44778 Abr '23

#44777 Sí.

Un saludo

Dr_Manhattan #44779 Abr '23

No me cites más que te acabo de silenciar.

Un saludo

Lolerpopler #44780 Abr '23 Cinturón negro

#44771 Pero nunca dijiste que hizo para desoptimizar la API 10000%

#44773 A mi BDD me parece util para QA (cuando no son muy tecnicos), ayuda tener esa interfaz para que la comunicacion con los desarrolladores sea mas precisa. Pero si toca hacer test end to end o tests de integracion de todo el sistema si o si. O uso algo como selenium para ciertos procesos criticos, como login, o tengo una suite que lanza un par de tests contra un entorno que esta configurado para testear y que si requiere cosas de terceros usan el sandbox o respuestas dummy.

En un momento dado estaba trabajando en un entorno que tenia muchos "smoke tests" que testeaba tanto otros servicios de nuestra compañia como de terceros. Yo me encargue de liquidar muchos de esos tests Practicamente todos los que comprobaban nuestros servicios y, de los que testeaban software de terceros solo un par se quedaron.

Y lo de que si alguien causa un bug en algun microservicio, para eso estan los tests y las PRs, no? Si el servicio tiene sus tests que verifican que los endpoint se comportan acorde a los contratos, o has tocado esos tests para que se adapten a tu codigo y alguien deberia de decir algo en la PR o no habia coverage y has identificado un punto bug.
Si no es como llevar cinturon y tirantes, te tienes que fiar muy poco de tus pantalones

1 2 respuestas

Wei-Yu #44781 Abr '23

uno de los puntos fuertes que la gente le pone a trabajar en el mismo espacio físico es que hay interacciones orgánicas que no se dan en remoto (ej watercooler chat, juntarse después a birras, juntarse en la comida, conversaciones en los pasillos...)

alguien ha leído lo mismo aplicado a las horas muertas en el trabajo/trabajar de forma muy holgada? me da la sensación de que si tengo poco que hacer o poca cosa estimulante busco otros canales para mi energía

a veces esos canales son tocarme la polla a dos manos pero otras son cosas relacionadas con el curro

Fyn4r #44782 Abr '23 Inocente

2 palabras: Vampire Survivors

4 1 respuesta

Farmijo #44783 Abr '23

#44780Lolerpopler:
Pero nunca dijiste que hizo para desoptimizar la API 10000%

Tienen por ahí un follón de eventos y una cola generica que los acepta todos, el endpoint lo que hace por debajo hace una guarrada rollo while (eventXConsumed == false), así que básicamente se follan la gracia de que sea async sumado a la mierda de infra que tienen montada.

GaN2 #44784 Abr '23 Inocente

#44782 De la droga se sale, del Vampire Survivors no

Kaledros #44785 Abr '23

Soy un tío pacífico y en absoluto violento, pero a la gente que entra en canales de Slack de otros equipos y meten un @aquí para preguntar una mongolada que podría contestar el primero que mirase el canal, y que encima no tienen prisa y se puede responder en cualquier momento, los colgaba de los pulgares.

3 1 respuesta

JuAn4k4 #44786 Abr '23

#44785 No tenéis un canal #help-xxxx para el equipo ? Y el normal privado ? Nosotros tenemos el setup así, y nos rotamos el responder a ese canal cada semana

1 respuesta

Kaledros #44787 Abr '23

#44786 Algo así tenemos, pero ya te digo, estamos todos los del equipo leyendo los dos canales, si lo pones en el público tranquilo que en menos de cinco minutos te ha contestado alguien seguro. Que a ver, si se nos ha caído un servicio me parece bien que nos avisen con una alerta aunque ya estemos en ello, pero para preguntar cosas que te puedo responder mañana pues me jode.

pantocreitor #44788 Abr '23

Le estoy haciendo la entrevista hoy a uno...

Yo: Bueno, comentas que estás acostumbrado a trabajar con bases de datos SQL
Entrevistado: Si, pero no con SQL, solo con Oracle y MySQL, pero SQL no
Yo: Ok, entonces SQL no lo has tocado
E: No, pero hago los diseños de la base de datos que me pide el cliente porque soy también analista funcional
Yo: Ah ok, diseñas los diagramas y lo tratas con cliente para ver que todas las relaciones son correctas y demás no?
E: No no, a ver, yo hago una pantalla, se la enseño a cliente y si le gusta hago el microservicio correspondiente a esa pantalla y sus tablas, y así con cada pantalla que le enseño. Ya sabes metodologías ágiles, scrum, jira y eso.

Dice que tiene mas de 8 años de experiencia, que es analista senior y pide +50k...

Os juro que flipo con la gente, hay mas de uno que cree de verdad que soltando cosas aleatorias va a encontrar trabajo.

Por cierto, mañana es mi último día en NTT, el lunes que viene empiezo en la !consultora xD

3 5 respuestas

newfag #44789 Abr '23

@aquí qué gomina utilizáis?

3 respuestas

Soltrac #44790 Abr '23 MV Wizard

#44788 Se ha puesto nervioso y entiendo que quería decir SQL Server o algo así xDDDDD. Luego ya la otra chorrada....

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales