– Las pruebas unitarias se tienen que poder ejecutar sin necesidad de intervenci\u00f3n manual, mejorar la automatizaci\u00f3n de la ejecuci\u00f3n.<\/p>\n
– Las pruebas unitarias tienen que poder repetirse tantas veces como uno quiera, deben ser r\u00e1pidas.<\/p>\n
– Deben cubrir casi la totalidad del c\u00f3digo de nuestra aplicaci\u00f3n.<\/p>\n
– Deben poder ser ejecutadas bajo cualquier entorno, es decir, que los casos de error sean reales entre plataformas.<\/p>\n
– Deben ser independientes en su ejecuci\u00f3n, no puede afectar la ejecuci\u00f3n de otra.<\/p>\n
– Deben ser tratadas como si fueran c\u00f3digo (de la misma manera)<\/p>\n
Por lo que se demuestra que para que una prueba unitaria sea correcta debiera ser<\/strong> (no siempre es obligatorio):<\/p>\n Automatizable, Completas, Repetibles o Reutilizables, Independientes, Profesionales.<\/p>\n Por lo tanto, respondiendo a la pregunta inicial\u00a0 \u00bf Qu\u00e9 ventajas me proporcionan<\/strong> ?<\/p>\n La capacidad de encontrar errores a tiempo<\/strong>, minimizar los comportamientos program\u00e1ticos an\u00f3malos, \u00a0corregirles sin que se produzca efecto bola de nieve<\/strong> en nuestro desarrollo, aumentar la calidad en nuestros programas<\/strong>, maximizar la satisfacci\u00f3n del cliente (interno, externo)<\/strong>.<\/p>\n Alientan el cambio: Facilitan que el programador cambie el c\u00f3digo para mejorar su estructura (lo que se ha dado en llamar refactorizaci\u00f3n<\/strong>).<\/p>\n Minimizan \u00a0la integraci\u00f3n: Puesto que permiten llegar a la fase de integraci\u00f3n con un grado alto de seguridad de que el c\u00f3digo est\u00e1 funcionando correctamente. De esta manera se facilitan las pruebas de integraci\u00f3n<\/strong>. Que son otro tipo de pruebas con mayor grado de integraci\u00f3n.<\/p>\n Documentan el c\u00f3digo: Las propias pruebas son documentaci\u00f3n<\/strong> del c\u00f3digo puesto que ah\u00ed se puede ver c\u00f3mo utilizarlo.<\/p>\n Separaci\u00f3n de la interfaz y la implementaci\u00f3n<\/strong>: Dado que la \u00fanica interacci\u00f3n entre los casos de prueba y las unidades bajo prueba son las interfaces de estas \u00faltimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock<\/strong> (mock object) para simular el comportamiento de objetos complejos. Ojo seg\u00fan los foros he visto discrepancia entre lo que es un mock y un stubs, y la delgada l\u00ednea que los separa<\/strong>. Ambos son dos recursos que usamos en nuestras pruebas unitarias<\/strong> que nos permiten simular objetos<\/strong> con los que interact\u00faa el m\u00f3dulo de que est\u00e1 sometido a la prueba. Los stubs se basan m\u00e1s en el estado<\/strong> y los mocks permiten comprobar en detalle las llamadas <\/strong>realizadas entre ellos.<\/p>\n Los errores\u00a0 son m\u00e1s f\u00e1ciles de localizar.<\/p>\n Unit test en PHP<\/strong><\/p>\n Como he comentado, para poder realizar pruebas unitarias existen unas herramientas para facilitar su uso. Estas forman parte de frameworks de prueba. He seleccionado PHP por se un lenguaje de script del lado servidor muy empleado en la actualidad, no sin ello desmerecer a otros entornos, v\u00e1lidos y tambi\u00e9n ampliamente usados.<\/p>\n
![\"\"](\"http:\/\/www.palentino.es\/blog\/wp-content\/uploads\/2012\/07\/all_tests-php.jpg\" "\\"all_tests-php\\"")
<\/a><\/p>\n