{"id":9324,"date":"2019-09-25T14:39:06","date_gmt":"2019-09-25T12:39:06","guid":{"rendered":"https:\/\/www.makingscience.com\/blog\/mi-codigo-funciona-puedo-publicar-ya-tests-y-test-de-aceptacion\/"},"modified":"2019-09-25T14:39:06","modified_gmt":"2019-09-25T12:39:06","slug":"mi-codigo-funciona-puedo-publicar-ya-tests-y-test-de-aceptacion","status":"publish","type":"post","link":"https:\/\/www.makingscience.com\/es\/blog\/mi-codigo-funciona-puedo-publicar-ya-tests-y-test-de-aceptacion\/","title":{"rendered":"Mi c\u00f3digo funciona, \u00bfpuedo publicar ya? &#8211; Tests y test de aceptaci\u00f3n."},"content":{"rendered":"<div>Mi c\u00f3digo funciona, \u00bfpuedo publicar ya? &#8211; Tests y test de aceptaci\u00f3n.<\/div>\n<div><strong>La respuesta a la pregunta del t\u00edtulo es clara: NO<\/strong>.  Antes de la publicaci\u00f3n, el producto\/software debe haber pasado unos tests para que sea apto para su uso.  En este art\u00edculo veremos que los tests tienen un lugar muy importante en el desarrollo del software pero de alguna manera son considerados como una tarea tediosa y poco atractiva de realizar. Tienen motivos para que tengan esa mala fama, pero tambi\u00e9n veremos que no todos los tests son tan temibles como nos hacen ver.  Existen numerosos tipos de procesos en el desarrollo de software y a su vez, para cada proceso, existen diferentes tipos de test. Por ejemplo, seg\u00fan la metodolog\u00eda (est\u00e1ticas o din\u00e1micas), modo de ejecuci\u00f3n (manuales o autom\u00e1ticas) o dependiendo de lo que se quiera verificar en la fase del desarrollo del software (funcionales o no funcionales). Estas solamente son agrupaciones grandes (y no se han mencionado todas) y cada una de ellas se puede dividir en subgrupos y niveles para realizar todo tipo de pruebas para que el software, como m\u00ednimo, funcione.  Enfoc\u00e1ndose por niveles de tests se puede hablar de<strong> 4 grandes niveles: test unitario, test de integraci\u00f3n, test de sistema y test de aceptaci\u00f3n.<\/strong> Por los nombres y el orden de enumeraci\u00f3n se puede deducir que los niveles van de menor a mayor complejidad. Los test unitarios comprueban el correcto funcionamiento de los elementos (clases y\/o m\u00e9todos) de un sistema (software como producto final). En los tests de integraci\u00f3n se comprueba si los elementos que funcionan correctamente por separado siguen funcionando cuando se ensamblan. Es decir, de nada sirve que hayan aprobado los tests unitarios si al hacer la integraci\u00f3n de cada unidad no pasa el test de integraci\u00f3n.  Esto no solo afecta al desarrollo de software, ya que podemos encontrarnos casos donde el test de integraci\u00f3n no ha sido superado. La imagen es un claro ejemplo de lo que se acaba de describir: dos m\u00f3dulos que funcionan correctamente por separado pero el resultado al integrarlos no es el deseado:  <img decoding=\"async\" src=\"https:\/\/www.makingscience.com\/wp-content\/uploads\/2021\/04\/giphy.gif\" alt=\"Technology Fail GIF\" \/>  Continuando con los <strong>tests de sistema<\/strong>, estos sirven para comprobar si el sistema totalmente integrado como producto final, cumple con todos los requisitos.  Por \u00faltimo, los tests de aceptaci\u00f3n son los que se realizan antes del lanzamiento del producto, probando todo el sistema o producto en un entorno y condiciones lo m\u00e1s parecidos a los de producci\u00f3n posibles. Dentro de este nivel tambi\u00e9n existen dos sub-tipos, los tests de aceptaci\u00f3n de operaci\u00f3n (OAT) y de usuario (UAT).  Los <strong>tests de aceptaci\u00f3n<\/strong> de operaci\u00f3n son pruebas no funcionales, b\u00e1sicamente se enfocan en si el software es capaz de funcionar en el sistema o en el entorno de producci\u00f3n, mientras que las pruebas de aceptaci\u00f3n de usuario se dedican a comprobar el cumplimiento de los requisitos de la funcionalidad del software que se hab\u00eda acordado en la planificaci\u00f3n.  Para finalizar, vamos a ver un peque\u00f1o ejemplo de la <strong>estructura de un test de aceptaci\u00f3n de usuario.<\/strong>  Las pruebas para test de aceptaci\u00f3n de usuario se preparan con un lenguaje de alto nivel, a ser posible por los usuarios finales que no tienen porqu\u00e9 estar al tanto del proceso de implementaci\u00f3n, si no de verificar si cumple con las funcionalidades de las especificaciones y\/o requisitos establecidos, como se ha comentado anteriormente.  El lenguaje que se utiliza para los tests de aceptaci\u00f3n se llama Gherkin, y existen varios int\u00e9rpretes de este lenguaje, el m\u00e1s famoso de todos es Cucumber escrito en Ruby, y otros como Jasmine para JavaScript, Concordion para Java, Kahlan para PHP, o Behave para Python, que es el utilizado en los ejemplos de c\u00f3digo siguientes.  <img fetchpriority=\"high\" decoding=\"async\" class=\"alignnone size-full wp-image-2937\" src=\"https:\/\/www.makingscience.com\/wp-content\/uploads\/2021\/04\/unnamed.png\" alt=\"\" width=\"566\" height=\"130\" \/>  Vamos a detallar los elementos que aparecen en la figura anterior.  Feature ser\u00eda el t\u00edtulo y la descripci\u00f3n del test que se est\u00e1 realizando, Scenario describe un caso concreto que se quiere probar, es decir, cada funcionalidad donde interact\u00faan el usuario y el sistema ser\u00eda un escenario.  En el escenario se describen las precondiciones, el evento y su resultado, estos se definen con las palabras Given, When y Then. And es otra palabra dentro del escenario que puede ir en diferentes partes del mismo y dependiendo de d\u00f3nde se ubique, a\u00f1ade mayor descripci\u00f3n.  El escenario habr\u00e1 pasado el test cuando ocurra el evento (When the user books 1 videocall), dadas ciertas precondiciones (Given a new user registered with username foo@bar.com And has 3 free videocalls) y cumpla con el resultado conocido de antemano (Then the user has 2 free videocalls left).  Abajo se muestra el resultado del test en Behave:  <img decoding=\"async\" class=\"alignnone size-full wp-image-2938\" src=\"https:\/\/www.makingscience.com\/wp-content\/uploads\/2021\/04\/unnamed-1.png\" alt=\"\" width=\"654\" height=\"189\" \/>  Como se puede observar, Gherkin ayuda a que el test sea con un lenguaje natural, conciso y f\u00e1cil de entender, a diferencia de otros tipos de test de m\u00e1s bajo nivel y para personas o equipos con conocimiento t\u00e9cnico.  En resumen, aunque los tests parezcan pesados y poco llamativos por su extensa variedad, cada uno de ellos cumplen una funci\u00f3n, y que aunque parezcan independientes entre unos y otros, est\u00e1n ligados de un nivel al pr\u00f3ximo para garantizar el correcto funcionamiento del software, por lo que merecen que se les d\u00e9 m\u00e1s atenci\u00f3n y dedicaci\u00f3n.  Adem\u00e1s, sabiendo que existen tests m\u00e1s amigables se puede hacer part\u00edcipe tanto a personal t\u00e9cnico como a no t\u00e9cnico en el desarrollo de software y control de calidad, ya que ambos roles juegan un papel muy importante como usuario final.  <img decoding=\"async\" class=\"alignnone size-full wp-image-2930\" src=\"https:\/\/www.makingscience.com\/wp-content\/uploads\/2021\/04\/meme-1.png\" alt=\"\" width=\"600\" height=\"400\" \/><\/div>\n","protected":false},"excerpt":{"rendered":"<p>Mi c\u00f3digo funciona, \u00bfpuedo publicar ya? &#8211; Tests y test de aceptaci\u00f3n. La respuesta a la pregunta del t\u00edtulo es clara: NO. Antes de la publicaci\u00f3n, el producto\/software debe haber pasado unos tests para que sea apto para su uso. En este art\u00edculo veremos que los tests tienen un lugar muy importante en el desarrollo [&hellip;]<\/p>\n","protected":false},"author":21,"featured_media":9329,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[34],"tags":[68],"class_list":["post-9324","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology-ai","tag-web-development"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts\/9324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/comments?post=9324"}],"version-history":[{"count":0,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts\/9324\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/media\/9329"}],"wp:attachment":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/media?parent=9324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/categories?post=9324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/tags?post=9324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}