{"id":981,"date":"2016-07-11T00:37:01","date_gmt":"2016-07-11T05:37:01","guid":{"rendered":"http:\/\/blog.espol.edu.ec\/taws\/?p=981"},"modified":"2016-07-11T20:32:39","modified_gmt":"2016-07-12T01:32:39","slug":"tests-unitarios-valen-la-pena","status":"publish","type":"post","link":"https:\/\/blog.espol.edu.ec\/taws\/2016\/07\/11\/tests-unitarios-valen-la-pena\/","title":{"rendered":"Tests Unitarios, \u00bfValen la pena?"},"content":{"rendered":"

Uno de los desaf\u00edos m\u00e1s grandes de la Ingenier\u00eda de Software\u00a0es lograr garantizar la calidad de los productos de software y mejorar la productividad a lo largo del ciclo de vida del mismo, desde el comienzo del desarrollo hasta las etapas de mantenimiento. B\u00e1sicamente que la vaina de programa no me complique la vida.<\/del><\/p>\n

A lo largo del tiempo de vida del proyecto surgen cambios en los requerimientos del software con lo cual muchas veces debemos modificar una funcionalidad ya establecida del sistema y es con estos cambios donde se pueden introducir nuevos errores. Estos errores a veces pueden ser f\u00e1cilmente detectados con una sencilla prueba manual del sistema, es decir, metes datos como loco<\/del> al programa y esperas a ver que sale; a medida que el proyecto crece en tama\u00f1o se torna algo imposible de lograr en un tiempo razonable, ya que estas pruebas \"manuales\" toman mucho m\u00e1s tiempo y por lo general son repetitivas, puede que en una de esas repeticiones no hayamos prestado la suficiente atenci\u00f3n y toma! un rico bug<\/em>\u00a0al cliente.
\nEste bug<\/em> a veces puede significar p\u00e9rdida de dinero de nuestros clientes o incluso peor, puede significar la vida de una persona, y es aqu\u00ed en donde la importancia de tener un \"repelente de bugs\" se torna m\u00e1s que necesario. nota: bug = error del sistema<\/del><\/p>\n

<\/p>\n

Si bien el testing no asegura que no existan fallas, s\u00ed permite evaluar la confiabilidad del producto a construir y dar una noci\u00f3n de la calidad del producto que se est\u00e1 construyendo. El testing permite detectar cu\u00e1ndo y c\u00f3mo el software falla.[1]<\/p>\n

Existen diferentes tipos de Tests:<\/p>\n

Test de aceptaci\u00f3n:<\/strong> es un test que permite comprobar que se est\u00e1 cumpliendo con un requerimiento del negocio. Son pruebas escritas en lenguaje del cliente pero que puede ser ejecutado con la m\u00e1quina. Esto nos permite probar que el software que estamos desarrollando cumple con las expectativas del cliente y de los usuarios.<\/del><\/p>\n

Test funcionales:<\/strong>\u00a0esta expresi\u00f3n es utilizada para determinar a aquellas pruebas que agrupan a varios tests de aceptaci\u00f3n y prueban alguna funcionalidad del negocio propiamente dicha.<\/p>\n

Test de sistema:<\/strong> integra varias partes del sistema, incluso puede probar toda la aplicaci\u00f3n o varias funcionalidades juntas. Estos tests se comportan de manera similar y buscan emular el comportamiento de los usuarios del sistema.<\/p>\n

Test unitarios:<\/strong> son los tests ineludibles, son los necesarios y los m\u00e1s importantes para los desarrolladores, todo test unitario debe ser r\u00e1pido, at\u00f3mico, inocuo e\u00a0independiente, sino cumple con estas cuatro premisas no es un test unitario. Un test tiene que ser r\u00e1pido porque se ejecutan muchos de ellos todo el tiempo, tiene que ser inocuo, ya que no debe alterar el estado del sistema, para ser at\u00f3mico debe probar la menor cantidad posible de c\u00f3digo y por \u00faltimo para ser independiente no debe depender de que otros tests unitarios sean exitosos o fallen para ser \u00e9l mismo exitoso. Un test unitario se aplica a una parte espec\u00edfica del c\u00f3digo.[2]
\nUna forma ch\u00e9vere de ver una analog\u00eda a los test unitarios es como la expone @benzado [3] a continuaci\u00f3n lo transcribo:<\/p>\n

El testing Unitario es como ir al gimnasio. T\u00fa sabes que es bueno para ti, todos los argumentos tienen sentido, entonces empiezas a ejercitarte. Hay un \u00edmpetu al principio, lo cual est\u00e1 bien, pero luego de varios d\u00edas empiezas a preguntarte si vale la pena tomarse la molestia. Est\u00e1s tomando una hora de tu d\u00eda para cambiarte de ropa, y ponerte a correr en una bola para hamsters y no est\u00e1s seguro si est\u00e1s ganando algo m\u00e1s que solo dolor de brazos y piernas.<\/p>\n

Luego, despu\u00e9s de una o dos semanas, tan pronto los dolores van desapareciendo, un gran Deadline se acerca. Tal vez te encuentres tan ocupado que necesitas invertir tu tiempo s\u00f3lo en lo que sea trabajo \u00fatil, entonces dejas de ir al gym. Empiezas a quitarte el h\u00e1bito y cuando el Deadline termina tratas de volver a lo que estabas haciendo antes de eso, ir al gimnasio. Si logras arregl\u00e1rtelas para convencerte en ir de nuevo, vas a sentir el mismo dolor que cuando fuiste la primera vez.<\/p>\n

Haces algo de investigaci\u00f3n, para ver si hay algo que est\u00e1s haciendo mal.\u00a0Empiezas a sentir un poco de rechazo a esas personas fit que siempre hablan de las virtudes de hacer ejercicios\u00a0y\u00a0a darte cuenta que no tienes nada en com\u00fan con ellas. Ellos no tienen que discutir con nadie acerca de los beneficios de los ejercicios; es algo que todos aceptan como importante. Cuando un Deadline se acerca, no tienen a un jefe que les dice que el ejercicio es innecesario y que s\u00f3lo deben dejar de tragar.<\/p><\/blockquote>\n

\n

Los test unitarios usualmente valen la pena el esfuerzo, pero la cantidad de esfuerzo que se tiene que hacer no es la misma para todos. Depende de que parte del desarrollo te encuentres al momento de empezar a hacer las pruebas. Si lo haces sobre una base de c\u00f3digo espaguetti<\/em> gigantesca y sin nada de testing, vas a estar bastante ocupado\u00a0jodido<\/del> y te va a tocar esforzarte mucho; en cambio si empiezas a testear desde el principio todo ser\u00e1 infinitamente m\u00e1s f\u00e1cil, es por esto que naci\u00f3 el TDD (Test-Driven-Development) cuya implementaci\u00f3n en un proyecto est\u00e1 demostrado que reduce del 40-80% la densidad de producci\u00f3n de bugs. [4]<\/p>\n

Como bien nos indica Jurado [2] los test unitarios son los m\u00e1s importantes y no deben eludirse, deben estar si o si, ya que son la base de otros\u00a0tipos de test m\u00e1s generales.<\/p>\n

<\/p>\n

Hay varios beneficios de realizar los tests unitarios:<\/p>\n

Menor cantidad de Bugs:
\n<\/strong>Esto puede sonar un poco obvio. Sin test, pruebas todo de manera manual, con un c\u00f3digo sencillito esto no es gran problema, pero cuando aumenta la complejidad se vuelve un problema. Y mientras m\u00e1s c\u00f3digo tengas, m\u00e1s tiempo te tomar\u00e1 hacerlo. Adem\u00e1s que hacerlo manualmente implica que debemos prestar mucha atenci\u00f3n a los resultados en cada vez que probemos manualmente.. que pueden ser muchas, muchas veces durante una cantidad de tiempo razonable. Pero si ponemos nuestro mejor esfuerzo y dedicamos tiempo a realizar nuestro test notaremos la ganancia de tiempo que obtendremos al final, y lo mejor es que los test siguen sirviendo a lo largo del desarrollo del proyecto, escribes el test una vez y te aseguras de jam\u00e1s volver a probar esa parte del c\u00f3digo.<\/p>\n

Tendr\u00e1s un repelente de Bugs:
\n<\/strong>Necesitas una explicaci\u00f3n para este beneficio? Si es as\u00ed aqu\u00ed tienes:
\nSi accidentalmente \u00a0haces un cambio que introduce un bug<\/em> (suele suceder m\u00e1s de lo que imaginas)<\/del>\u00a0en el c\u00f3digo que ya tiene un test unitario, el test detectar\u00e1 el bug<\/em>. Es decir, no dejar\u00e1 que haga da\u00f1o a ning\u00fan cliente en producci\u00f3n. \ud83d\ude09<\/p>\n

Podr\u00e1s desarrollar de forma segura:
\n<\/strong>Qui\u00e9n no ha escrito c\u00f3digo y ha pensado alguna vez \u00bfHabr\u00e9 cagado<\/del>\u00a0da\u00f1ado algo en otra parte? En un mont\u00f3n de proyectos sucede que si no se tiene tests unitarios, un cambio que haces en un lado, puede afectar en otra funcionalidad que ni tocaste, as\u00ed que solo pruebas manualmente la funcionalidad que hiciste y si funciona correctamente todo el mundo es arcoiris para ti, pero lo que no sabes es que hiciste la grande en otro lado y ni por enterado.<\/p>\n

Cuando ya se tiene una \"red\"<\/em> de tests unitarios \u00e9stos si son detectados, y me sentir\u00e9 seguro codificando porque si hago un cambio que\u00a0afecte\u00a0cague<\/del> otra funcionalidad el test de ese otro lado saltar\u00e1 y te dir\u00e1 que ha ocurrido mal.<\/p>\n

Esto te suena conocido? pues si, es como hacer debugging, pero autom\u00e1tico porque te dice:<\/p>\n

    \n
  1. qu\u00e9 funci\u00f3n fall\u00f3.<\/li>\n
  2. que se supon\u00eda que deb\u00eda de hacer esa funci\u00f3n.<\/li>\n
  3. que hizo la funci\u00f3n en vez de lo esperado.\u00a0esto es \u00fatil cuando el debugger del lenguaje es una caca, como el de javascript<\/del><\/li>\n<\/ol>\n

    El dichoso test sirve como documentaci\u00f3n del c\u00f3digo:
    \n<\/strong>Las razones ya fueron impl\u00edcitamente dadas en los otros beneficios \ud83d\ude09<\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

    Referencias:<\/strong><\/p>\n

    [1]D. Vallespir, 2016. [Online]. Available: https:\/\/www.fing.edu.uy\/~dvallesp\/wiki\/uploads\/Research\/gacpuo.pdf. [Accessed: 11- Jul- 2016].<\/p>\n

    [2]Carlos Ble Jurado, \u201cDise\u00f1o \u00c1gil con TDD\u201d, eBook. Primera Edici\u00f3n. Enero 2010. p\u00e1ginas 70-71.<\/p>\n

    [3]Is. 2016. \"Is Unit Testing Worth The Effort?\". Stackoverflow.Com<\/i>. Accessed July 11 2016. http:\/\/stackoverflow.com\/questions\/67299\/is-unit-testing-worth-the-effort.<\/p>\n

    [4]\"TDD - The Art Of Fearless Programming | SEED: Software Engineering Evidence Database\". 2016. Evidencebasedse.Com<\/i>. Accessed July 11 2016. http:\/\/evidencebasedse.com\/?q=node\/78.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Uno de los desaf\u00edos m\u00e1s grandes de la Ingenier\u00eda de Software\u00a0es lograr garantizar la calidad de los productos de software y mejorar la productividad a lo largo del ciclo de vida del mismo, desde el comienzo del desarrollo hasta las etapas de mantenimiento. B\u00e1sicamente que la vaina de programa no me complique la vida. A […]<\/p>\n","protected":false},"author":9990,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[136328],"tags":[36666,144818,136331,136328,136330],"class_list":["post-981","post","type-post","status-publish","format-standard","hentry","category-testing","tag-agile","tag-bugs","tag-tdd","tag-testing","tag-unit-testing"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/posts\/981","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/users\/9990"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/comments?post=981"}],"version-history":[{"count":9,"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/posts\/981\/revisions"}],"predecessor-version":[{"id":994,"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/posts\/981\/revisions\/994"}],"wp:attachment":[{"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/media?parent=981"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/categories?post=981"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/taws\/wp-json\/wp\/v2\/tags?post=981"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}