En el desarrollo de un proyecto, existen muchos factores que pueden hacer que nada resulte como se planeó,, entre ellos puedo mencionar, desconocimiento de escenarios que ni el propio cliente conoce, flujos de trabajo que se creen que se conocen, a veces la propia capacidad del programador a cargo, mal manejo de la información y finalmente el tema del artículo, integraciones de servicios externos, alguna API, un Webservices, en fin cualquier servicio que se tiene que consultar.
Hoy en día hay múltiples servicios en la “nube”, que podemos consultar sin problemas o ese debería ser el caso. Pero desafortunadamente existen servicios poco documentos, o por lo contrarios tan documentados, que marean a la hora de la construcción. Y las pruebas de escenarios.
Por varios años me a tocado realizar integraciones con terceros, algunos con suerte funcionan a la primera. sin tener que siguiera enviar un correo, para preguntar algo. Pero hay otros en los que pff fue tan empinado el trayecto que hasta tenía pesadillas al respecto.
Para evitar que tengas pesadillas, te comparto lo que he aprendido.
Lo primero es probar los servicios en bruto, que quiero decir si es un soap puedes utilizar soapUI el cual te permite cargar wsdl y te crea los xml para consultar los servicios. Ideal para hacer los ejemplos. Si por el contrario es un REST, pues intenta con postMan que también te permite generar las peticiones en bruto. El objetivo es testear los servicios antes de comenzar a programar.
Solicita toda la documentación disponible y la más reciente. Por X o Y razón a veces parece obvio para todos que la documentación que se tiene es la correcta. Pero siempre hay que confirmarlo, ya sea al preguntar algo a soporte o hacer mención de en X pagina de este documento dice Tal cosa, de esta manera puedes confirmar que todos hablan el mismo lenguaje. En una ocasión estuve trabajando con otra documentación perdí muchas horas de trabajo, solo por que no lo confirme.
Logs siempre siempre programa una forma de tener registros de cada solicitud, respuesta y error que entra y sale del servicio en desarrollo. Más vale tener las herramientas y las evidencias de lo que está ocurriendo. Para encontrar en donde esta el error, por que como es estar trabajando con una caja negra, en la cual recibe parámetros y genera un resultado. No podemos estar seguro si es nuestra culpa o es culpa de la dichosa caja.
Pruebas en vivo es muy pero muy importante que se programe si es posible, hacer pruebas en conjunto y se vuelve URGENTE si el desarrollo no avance según los planeado. En las pruebas en vivo, es poder estar en constante comunicación con el proveedor de servicio y poder verificar lo que le estamos enviado. lo que el proveedor está recibiendo y comparar qué está pasando o qué es lo que debería estar sucediendo.
Comunicación es indispensable comunicar cualquier problema o inconveniente que se encuentre sin importar que tan pequeño sea. Ya sea por correo, llamada o en persona. donde se plantee la duda, el escenario y bajo qué condiciones se hace una petición. A veces queremos solucionarlo todo por nuestra cuenta y el error puede ser tan sencillo que no lo vemos.
Automatiza tus pruebas en aquellos servicios en los cuales su documentación es muy extensa y en los cuales tienen escenarios muy complejos, es muy recomendable que crees un set pruebas, que puedas ejecutar y te diga que todo va bien. En otras palabras implementa pruebas unitarias, muchos lenguajes ya tienen formas de hacerlos.
Añadir nuevo comentario