Dudas sobre BDD en una API

[Pablo Bouzada]

Hola, 

creo que lo primero que tengo que hacer es presentarme, porque aunque llevo tiempo siendo miembro esta es mi primera participación (si la memoria no me falla):

Me llamo Pablo Bouzada (@pbousan en Twitter) y soy desarrollador, llevo algunos años programando en C# aunque también me he peleado con otros. Formo parte de Programando en .NET (http://programandonet.com/web/), CatDotNet (http://catdotnet.net/) y algún que otro grupo de usuarios.

Me gustaría preguntar, o más bien abrir un debate, sobre cómo plantear una aproximación con BDD cuando se va a desarrollar una API. Estuve buscando información sobre este tema y encontré esto:

http://www.pragmaticapi.com/2013/01/12/bdd-atdd-for-your-agile-rest-api/

http://www.pragmaticapi.com/2013/01/21/bdd-atdd-for-your-agile-rest-api-part-2/

(me vais a perdonar, pero personalmente me sobra el adjetivo "agile" en todo esto)

que me parece una aproximación interesante, aunque creo que se queda en la superficie. Primero porque el escenario es muy sencillo, y segundo porque únicamente se centra en testear métodos GET, dejando de lado los POST, PUT y DELETE, que son los realmente interesantes.

Pongamos un ejemplo un poco más complejo: supongamos que en nuestra API, vamos a tener un método POST que, además de crear un recurso (en base de datos o donde sea) y devolver la URL del nuevo elemento, va a realizar otra acción como puede ser enviar un e-mail, escribir en un fichero o enviar un mensaje a un BUS. 

¿Cómo debería ser la especificación? ¿Debería quedarse en comprobar que la API devuelve un código 200 (OK) o 201 (Created) y que envía como respuesta una URI válida?

¿o tendría que comprobarse también que se realiza la siguente acción (enviar mail, mensaje o escribir a fichero)?

Saludos,

Pablo

 

[Matias Mascazzini]

Aunque parezca simple te voy a decir lo siguiente, leelo y meditalo, porque para mi es la clave:

BDD se enfoca en el comportamiento esperado

¿Comportamiento según quien? es la pregunta clave

En tu caso el consumidor de la API. ¿Qué ve?¿Cuando lo ve?¿Que hace ese consumidor para ver ese comportamiento?

Qué hace y cómo lo hace internamente tu API para reflejar ese comportamiento esperado, eso sí a mi entender, podes hacer que surja con TDD.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

[Pablo Bouzada]

Matías, gracias por la respuesta. Ese justo es el matiz que me cuesta definir, supongamos que el caso es que un POST crea un elemento en base de datos y además envía un email. 

Tiene que hacer ambas cosas, pero para el consumidor  de la API sólo habrá una respuesta (la respuesta HTTP). El email será enviado a un usuario que lo tendrá que recibir en su inbox, pero el requisito (behavior) es igualmente importante.

En los tests unitarios está claro qué hay que probar, pero en los de aceptación no lo tengo tan claro...

[Vicenç Garcia]

Hola buenas,

tengo una experiencia limitada con BDD (con ganas de ir incrementando esto) pero yo creo que se debería comprobar todo lo que se espera que haga. Si espero que envie un correo miro que se haya enviado y si espero que se haya escrito en la base de datos, miro que realmente se haya escrito.

Pero vamos, estoy abierto a que me apaleéis y me contéis como hay que hacerlo de verdad :-)

Salut!

Vicenç

--
Has recibido este mensaje porque estás suscrito al grupo "TDDev" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a tddev-sp+u...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/tddev-sp.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Vicenç García

http://vgaltes.com

http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

[Alfredo Casado]

Si se trata de un test de aceptación, para que el cliente "acepte" la feature tendrás que probar el envío del mail, ¿si lo hicieras manualmente lo probarías?, pues lo mismo.

Eso si, probablemente yo tendría test diferentes, uno donde se probase que se crea el objeto X, otro donde se pruebe que se envia el mail a Y etc,etc.

--

[Pablo Bouzada]

Sí, eso por supuesto, sería un test para cada "acción".

Gracias por la respuesta Alfredo ;)

[Matias Mascazzini]

Para mi, entonces tu prueba tiene que estar en verde cuando el consumidor recibe esta respuesta http correcta y rojo en otro caso.

Lo del envío del email, lo puedes testear como un Paso Interno del comportamiento, sobre todo si de su correcta salida/llegada depende la respuesta http.
Sino el envío del email lo podríamos ver como otro comportamiento esperado.

¿Qué opinan el resto de los co-listeros?

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

--

[Pablo Bouzada]

Creo que has dado con la pieza que me faltaba: la respuesta de la API no depende de que el email se envíe, por lo que, como bien dices, es un paso interno del comportamiento.

[Vicenç Garcia]

Yo creo que si el comportamiento que espera el cliente ( una condición de aceptación de la feature ) es que cuando haga esa llamada se tiene que enviar un mail a fulanito y que se persista algo, hay que comprobar que el mail a fulanito se ha enviado y que se ha persistido algo.

[Miguel San Román]

Buenas, creo que es mi primer post por aqui, asi que me podeis apalear tambien :D

Creo que desde el punto de vista de consumidor de la API, el envio de mail me es indiferente. Es un comportamiento secundario que se ejecuta tras observar una accion determinada.

Con eso quiere decir que mantendria separados ambos conceptos, en todo caso tendria un observador de eventos que envia un mail en funcion de que ha ocurrido. Asi mi API se centraria... en ser una API.

Un saludo :)

—
Sent from Mailbox

[Pablo Bouzada]

Hola Miguel,

estoy de acuerdo que como consumidor de la API el envío del mail es indiferente, pero... y es un gran PERO, creo que el criterio de aceptación sí que lo debería incluir porque es parte del requisito del cliente.

Por supuesto no estoy diciendo que se deba probar que efectivamente la API envía el mail, eso sería ya un test de integración, pero sí que se hace una llamada a una clase, componente o incluso otro servicio que lo haga (moqueándolo, por supuesto, no tiene que ser el objeto real).

Saludos,

Pablo

[Carlos Ble]

Hola!

En mi opinion, los tests end-to-end conviene que sean de tipo "caja negra", es decir que no sepan los detalles de lo que ocurre por dentro. Ya sabes, "el qué" y no "el cómo". Ahora bien, enviar un email es un detalle interno, o el que invoca a la API está esperando que ocurra?

Si como consumidor de la API, espero que me llegue un 200 y que le llegue un email a fulanito, entonces mi test end-to-end se conectará al servidor POP/IMAP para verificar que ha llegado un correo. En el test, el acto es una llamada HTTP y la verificacion es conectarse  al servidor de correo y ver que ha llegado el email. Al fin y al cabo es un test de "validacion de estado".

Ahora bien, por motivos de coste/pragmatismo, igual te conviene que el test solo valide el 200 y luego ir manualmente y mirar el correo. Depende de cuántas veces se lance el test, cuantas veces cambia el codigo que hace eso, cuanto cuesta escribir el test, cuán frágil es el test...

Despues como bien se ha comentado, ya por dentro igual quieres usar tests mas pequeños y tirar de dobles (o no).

Saludos :-)

Carlos Ble

www.CarlosBle.com - @carlosble 

Check out my latest app for team productivity: www.liveTeamApp.com

Author of the first book on TDD in Spanish: www.dirigidoPorTests.com/el-libro

[Pablo Bouzada]

Carlos, gracias por la respuesta.

El tema es que como consumidor de la API sólo te interesa el resultado HTTP, pero el requisito por parte del cliente (y creo que eso es lo impotante) es que además se envíe el email. Por tanto creo que para que el test de aceptación pase, debería comprobarse que efectivamente se envía el email, o en este caso, que se llama al servicio encargado de enviar emails (que ya gestiona el envío por SMTP, tiene control de reintentos, ...)

Saludos,

Pablo