automatizar las pruebas? • Herramientas para pruebas unitarias - junit (Java) - minitest (Ruby) - phpunit (PHP) • Codigo heredado (legacy code) y refactorización • Pruebas y programación orientada a objetos • Pruebas automatizadas en el flujo de desarrollo profesional • Desarrollo basado en pruebas (TDD) • Integración continua • Otras herramientas
que se encargar se asegurar el correcto funcionamiento de una entidad (método o clase) Las pruebas unitarias son esenciales para toda compañia de desarrollo de software ya que ayudan a entregar un software de buena calidad a sus clientes
manera manual. Require de un tester/QA que ejecute el rol de un usuario final y que use la mayoría de las funcionalidades de la aplicación para asegurar su correcto compotarmiento Para asegurar que las pruebas sean completas, el tester/QA suele seguir un plan por escrito que lo guía mediante una serie de casos de uso importantes
del software que se está probando) para controlar la ejecución de pruebas y la comparación de las salidas actuales de la aplicación con las salidas previstas. La automatización de pruebas nos permite ejecutar de manera recurrente pruebas repetitivas pero necesarias, o añadir una capa de prueba adicional que sería difícil de hacer de manera manual
necesarios para correr una prueba. El desarrollador debe establecer el estado necesario antes de correr las pruebas y regresar al estado origin después de haber corrido las pruebas.
o estado de la unidad que está siendo probada. Las aserciones suelen expresar una condición lógica que es verdadera para los resultados esperados. El fallo de dicha aserción suele lanzar una excepción, abortando el resto de las pruebas actuales.
que ya no tiene soporte. El término fue primeramente utilizado por el científico computacional George Olivetti para referirse a código mantenido por un administrador que no desarrolló el sistema.
código y reducir su complejidad; esto puede mejorar la mantenibilidad del código fuente y crear una estructura interna más expresiva o el modelado de los objetos para mejorar la extensibilidad. Típicamente, al refactorizar se aplican una seria de micro-refactorizaciones básicas estandarizadas, cada una de ellas es usualmente un pequeño cambio en el código que o preserva el comportamiento del software, o al menos no modifica su apego a los requerimientos funcionales.
a los “cinco principios” mencionados por Robert C. Martin. Estas siglas significan cada uno de los cinco principios básicos para programación y diseño orientado a objetos. S.O.L.I.D.
que no usa ni deberian ser forzado a depender de métodos que no utilliza. A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use. Interface Segregation Principle
concretas. Se establece que los módulos de alto nivel no deben depender de módulos de bajo nivel, pero pueden depender de abstracciones. Dependency Inversion Principle
en la calidad del software y la flexibilidad a los cambios de requerimiento por parte del cliente. Al ser un tipo de metodología Agile, prioritiza lanzamientos frecuentes en pequeños periodos de desarrollo con el afán de mejorar la productividad e introducir puntos de referencia donde es posible agregar o cambiar requerimientos Programación Extrema (XP)
donde el desarrollador primero escribe una prueba (inicialmente fallida) que define el comportamiento de la nueva función, después produce el mínimo código necesario para hacer que la prueba pase, y finalmente refactoriza el nuevo código para que logre los estándares acordados
escribir una prueba, el programador debe entender las especificaciones y requerimientos de la funcionalidad. El programador puede lograr esto medienta casos de uso e historias de usuario. También se puede iniciar modificando una prueba ya existente. Agregar una prueba
la nueva prueba no pasa sin requerir código nuevo, y que la funcionalidad no exista ya en el sistema. Este paso también prueba la prueba por si misma. La nueva prueba debe fallar por la razón esperada. Correr las pruebas y verificar que la nueva falle
la prueba pase. El nuevo código escrito en este paso no es perfecto y puede, por ejemplo, pasar la prueba en una manera poco elegante. Esto es aceptable ya que se mejorará en el punto 5. Escribir código
de que el nuevo código cumple los requerimientos de la prueba y no rompe funcionalidad existente. En caso de que algo falle, se sigue ajustando el código. Correr las pruebas
generales y específicas sobre cómo refactorizar y cómo crear código limpio. Al correr continuamente las pruebas, el programador tiene la certeza de que el proceso no altera funcionalidad existente. Refactorizar el código
de forma continua, evitando el caos de última hora cuando se acercan las fechas de entrega. • Disponibilidad constante de una versión para pruebas, demos o lanzamientos anticipados. • Ejecución inmediata de las pruebas unitarias. • Monitorización continua de las métricas de calidad del proyecto. Ventajas https://es.wikipedia.org/wiki/Integraci%C3%B3n_continua
SiteGround - Reliable hosting with speed, security, and support you can count on.
ferperales
nari_ex
fossamagna
iwatatomoya
vtryo
jnishime_dresscode
tutcreators
i35_267
bengo4com
nwiizo
saku0512
chmikata
pokohide
.jpg){kind=avatar}
cargoodrich
schroneko
soudai
auna
codingconduct
takai
deanohume
elsirapls
jonoalderson
bkeepers
soysaucechin
addyosmani
![¡Gracias! [email protected] Feedback http://goo.gl/forms/WjhtvLSHj9](https://files.speakerdeck.com/presentations/8b44673951e647418063b03ab7dfcd98/slide_82.jpg){kind=link}