Nuestro ejemplo es muy simple: tenemos una clase que nos permite enviar notificaciones por mail a una lista de usuarios identificados por su nombre de usuario. Esta dependerá de una clase que devuelve información sobre los usuarios (en principio a partir de una base de datos, aunque en nuestro ejemplo lo hemos simplificado) y otra clase que permite enviar mails.<\/p>\n
<\/p>\n
![\"\"](\"http:\/\/yuml.me\/diagram\/scruffy\/class\/%5BNotifier%5D-%3E%5BUserRepository%5D,%20%5BNotifier%5D-%3E%5BMailer%5D.png\")
<\/p>\n
<\/p>\n
users.py<\/h3>\n
Esta es la clase que debería consultar la base de datos para obtener la información, pero como no es el objetivo del artículo, haremos que tenga esta funcionalidad tan simple.<\/p>\n
\r\nclass UserRepository:\r\n def get_user(self,username):\r\n return {"username:":username,"mail":username+"@upc.edu"}<\/pre>\n\nmailer.py<\/h3>\n\r\nimport smtplib\r\nfrom email.mime.text import MIMEText\r\n\r\nsender="reply@fib.upc.edu"\r\n\r\nclass Mailer:\r\n def send_mail(self,mail,subject,body):\r\n msg = MIMEText(body)\r\n msg['Subject'] = subject\r\n msg['From'] = sender\r\n msg['To'] = mail\r\n\r\n s = smtplib.SMTP('localhost')\r\n s.sendmail(sender, [mail], msg.as_string())\r\n s.quit()<\/pre>\nnotifier.py<\/h3>\n\r\nfrom users import UserRepository\r\nfrom mailer import Mailer\r\nimport sys\r\n\r\nclass Notifier:\r\n def __init__(self,user_repository=UserRepository(),mailer=Mailer()):\r\n self.user_repository=user_repository\r\n self.mailer=mailer\r\n\r\n def notify(self,message,usernames):\r\n for username in usernames:\r\n user=self.user_repository.get_user(username)\r\n mail=user['mail']\r\n self.mailer.send_mail(mail,message,message)\r\n\r\nif __name__ == "__main__":\r\n notifier=Notifier()\r\n notifier.notify (sys.argv[1],sys.argv[1:])<\/pre>\nSi queremos<\/span> podemos<\/span> ejecutar el programa<\/span> pasando<\/span> el mensaje<\/span> y la lista<\/span> de<\/span> usernames<\/span> como parámetros<\/span><\/span><\/p>\n\r\n$python notifier.py "Agafa les claus de casa" jaume.moral albert.obiols<\/pre>\nDado este sistema, como podemos hacer pruebas que realmente se envíen mails correctamente … sin que realmente se envíen? Como podemos simular que el UserRepository nos devuelva un cierto valor para poder probar nuestro código? Y sobre todo y no menos importante … como poder hacer esto de una forma fácil?<\/p>\n
Antes de continuar, debemos decir que ya de entrada hemos tomado una decisión de diseño que nos ayudará a escribir pruebas por nuestro código: hemos creado la clase Notifier de forma que le podamos "inyectar" las dependencias, es decir, pasarle por parámetro en el momento de la creación los objetos con los que se deberá comunicar, en vez de crearlos ella misma. Esto nos facilita la sustitución de estas dependencias durante las pruebas.<\/p>\n
Pruebas unitarios con "unittest"<\/h2>\n
Unittest es un paquete estándar de Python que permite, como su nombre indica, hacer pruebas unitarios. La forma de usarlo es parecido al JUnit de Java, y básicamente consiste en<\/p>\n
\n- Hacer una clase que extienda unittest.TestCase<\/li>\n
- Añadir métodos que empiecen por "test_" con la implementación de las pruebas<\/li>\n
- Hacer aserciones para comprobar que el resultado es el esperado<\/li>\n<\/ul>\n
Para empezar, haremos una pequeña prueba para testear la implementación "de mentira" que hemos hecho de nuestro servicio de usuarios. Sabemos que si vamos a buscar el usuario "jaume.moral" el mail que nos debería devolver se "jaume.moral@upc.edu". Escribiremos un test para codificar este comportamiento.<\/p>\n
\r\nimport unittest\r\nfrom users import UserRepository\r\n\r\nclass NotificationsTestCase(unittest.TestCase):\r\n\r\n def test_user_repository(self):\r\n users=UserRepository()\r\n user=users.get_user("jaume.moral")\r\n self.assertEquals("jaume.moral@upc.edu",user['mail'])\r\n\r\nif __name__ == '__main__':\r\n unittest.main()\r\n<\/pre>\nGuardaremos este código en un fichero “test.py” y la ejecutamos<\/p>\n
\r\n$ python test.py\r\n.\r\n----------------------------------------------------------------------\r\nRan 1 test in 0.000s\r\nOK<\/pre>\nEste test parece una tontería, pero ahora imaginemos que empezamos a hacer una implementación que se conecte al servicio de directorio real. Querremos asegurarnos que cuando pedimos el mail nos sigue devolviendo lo que toca. El test nos sirve para asegurarnos de que no rompamos cosas que ya funcionaban.<\/p>\n
Pruebas sustituyendo funcionalidades con "mock"<\/h2>\n
Pasamos ahora a un test más complicado. Queremos testear nuestro notificador que, como sabemos, depende directamente de UserRepository y de Mailer.<\/p>\n
Para hacer estas pruebas, tendremos que sustituir los objetos reales por unos de mentira. Queremos que tengan los mismos métodos con los mismos parámetros, pero que no hagan nada. Bueno, realmente lo que queremos es que hagan 2 cosas:<\/p>\n
\n- que nos devuelvan los valores que a nosotros nos van bien cuando ejecutamos un test en concreto<\/li>\n
- que podamos consultar si se ha hecho una cierta llamada a un método<\/li>\n<\/ul>\n
Para hacer esto en Python, tenemos el módulo "mock", que es parte de la librería estándar desde la version 3.0 y que se puede descargar en https:\/\/pypi.python.org\/pypi\/mock para las versiones anteriores. El repositorio GitHub con los ejemplos hay también el paquete.<\/p>\n
Test con una lista vacía de usernames<\/h2>\n
Vamos paso a paso: imaginemos primero que queremos enviar una notificación a una lista vacía de usernames. Nuestro UserRepository de mentira no tendrá que hacer nada y nuestro Mailer tampoco deberá enviar ningún email. Así pues, nuestro test podrá ser algo como esto:<\/p>\n
\r\n def test_0_user(self):\r\n users=mock.create_autospec(UserRepository)\r\n mailer=mock.create_autospec(Mailer)\r\n notifier=Notifier(users,mailer)\r\n notifier.notify(self.text,[])\r\n self.assertEquals(mailer.send_mail.call_count,0)<\/pre>\nLa función "create_autospec" lo que hace es crear un objeto con una interfaz igual que la clase que le pasamos, pero sin comportamiento. Esto es lo que llamamos "mock"<\/p>\n
Este mock guarda información sobre las llamadas que se hacen y por ello podemos consultar cuántas veces se ha llamado al método send_mail con la sintaxis mailer.send_mail.call_count<\/p>\n
Test con 1 username<\/h2>\n
Imaginemos ahora que envíen el mail a una lista de un usuario, concretamente el usuario "jaume.moral"<\/p>\n
En este caso, nuestro UserRegistry nos deberá devolver un objeto usuario con el mail de este usuario (jaumem@fib.upc.edu) y tendremos que comprobar que hemos llamado a la función send_mail con este mail y el texto que hemos pasado el notificador.<\/p>\n
Simular este comportamiento es tan simple como asignarle un valor al atributo "return_value" del método del objeto "mockejat"<\/p>\n
\r\n def test_1_user(self):\r\n users=mock.create_autospec(UserRepository)\r\n users.get_user.return_value={"mail":"jaumem@fib.upc.edu"}\r\n mailer=mock.create_autospec(Mailer)\r\n notifier=Notifier(users,mailer)\r\n notifier.notify(self.text,["jaume.moral"])\r\n mailer.send_mail.assert_called_with("jaumem@fib.upc.edu",self.text,self.text)<\/pre>\nAquí la aserción es un poco más compleja: estamos comprobando no sólo que hemos llamado el método send_mail, sino que la hemos llamado con unos parámetros en concreto.<\/p>\n
Como podemos ver, la idea de estos tests es siempre preparar el objeto falso porque nos devuelva unos datos conocidos y\/o comprobar que hemos llamado ciertos métodos del objeto falso.<\/p>\n
Test con 2 usernames<\/h2>\n
Muy bien, ahora que ya sabemos que nuestros objetos mockeados nos devuelven el valor que le hemos dicho … como hacemos que si lo llamamos más de una vez nos devuelvan objetos diferentes? Pues creando un "side effect". En vez de asignar el "return_value", que es estático, asignaremos un valor a la propiedad "side_effect" del método. Podemos asignarle una función o, en nuestro caso y para simplificar, una lista los elementos de la cual irá devolviendo uno por uno cada vez que llamamos el método.<\/p>\n
La idea de cambiar el código que ejecuta un método de un objeto en tiempo de ejecución es lo que se conoce como "monkeypatching". Es una técnica peligrosa pero que utilizada para testear se convierte en extremadamente útil, especialmente cuando está controlada por una librería específica como es este caso.<\/p>\n
\r\n def test_2_users(self):\r\n users=mock.create_autospec(UserRepository)\r\n users.get_user.side_effect=[{"mail":"jaumem@fib.upc.edu"},{"mail":"anna@fib.upc.edu"}]\r\n mailer=mock.create_autospec(Mailer)\r\n notifier=Notifier(users,mailer)\r\n notifier.notify(self.text,["jaume.moral","anna.casas"])\r\n mylist=[\r\n call("jaumem@fib.upc.edu",self.text,self.text),\r\n call("anna@fib.upc.edu",self.text,self.text)\r\n ]\r\n self.assertEqual(mailer.send_mail.call_args_list,mylist)\r\n<\/pre>\nEn este caso la aserción comprueba si hemos hecho una serie de llamadas con sus respectivos parámetros. Una aserción más simple sería ver que hemos llamado al send_mail 2 veces, pero la opción elegida es mucho más expresiva.<\/p>\n
Conclusiones<\/h2>\n
Testear en Python es fácil y tenemos formas mucho más simples y potentes que las que nos ofrecen lenguajes más estrictos como Java.<\/p>\n
En este artículo sólo hemos rascado un poco la superficie de lo que nos ofrecen las librerías Mock y Unittest. Hay otras formas de utilizarlas como aplicando el decoratorpatch, la clase MagicMock … pero todo esto lo dejamos para el lector que tenga curiosidad.<\/p>\n
Puede encontrar todo el código de los ejemplos a https:\/\/github.com\/jaumemoral\/python-testing\/<\/p>\n","protected":false},"excerpt":{"rendered":"
Test unitarios, de integración, regresión, aceptación, comportamiento, TDD… Hay muchos tipos de test y técnicas de testing y muchas veces la frontera entre ellas no es tan clara como quisiéramos.<\/p>\n","protected":false},"author":594,"featured_media":1722,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"experteses":[27],"class_list":["post-1726","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized-ca","experteses-knowledgeyserviceengineering-es"],"acf":[],"_links":{"self":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/1726","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/users\/594"}],"replies":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/comments?post=1726"}],"version-history":[{"count":0,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/1726\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media\/1722"}],"wp:attachment":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media?parent=1726"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/categories?post=1726"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/tags?post=1726"},{"taxonomy":"experteses","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/experteses?post=1726"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}