Unit tesing y el mito de los 0 bugs
•Descargar como PPSX, PDF•
1 recomendación•768 vistas
Como desarrolladores tenemos que crear el mejor código posible, que sea eficiente y que realice correctamente las funciones para las que ha sido creado: calidad. Una buena forma de conseguir esta buena calidad es probando nuestro código. Creando unit tests (pruebas unitarias) para cada una de las diferentes funcionalidades e intentando acercarnos lo máximo posible a una cobertura completa. Pero de nada sirve obligar al equipo a cubrir un 80% de código, si las pruebas que realizan no aportan valor. A lo largo de esta charla estudiaremos la mejor forma de probar código: Diferenciaremos entre los diferentes tipos de pruebas, sentaremos las bases de un buen unit test, nos ayudaremos de herramientas de diagnóstico y métricas de código, y refactorizaremos para conseguir código "testeable".
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (19)
Similar a Unit tesing y el mito de los 0 bugs
Similar a Unit tesing y el mito de los 0 bugs (20)
Más de Fernando Escolar Martínez-Berganza
Más de Fernando Escolar Martínez-Berganza (20)
Último
Último (15)
Unit tesing y el mito de los 0 bugs
- 1. Unit tesing Y el mito de los 0 bugs
- 4. Indice • Definicion de unit test • Estructura de un unit test • Haciendo codigo testeable • Ventajas e inconvenientes • Frameworks
- 5. Que es una prueba de software Input Process Output
- 6. Que es una prueba de software Input Process Output
- 7. Clasificación de las pruebas White-Box testing Black-box testing Visual testing Grey-box testing
- 8. Clasificación de las pruebas White-Box testing Black-box testing Visual testing Grey-box testing Unit testing Integration testing System testing Acceptance testing
- 9. Clasificación de las pruebas White-Box testing Black-box testing Visual testing Grey-box testing Unit testing Integration testing System testing Acceptance testing Installation testing Compatibility testing Smoke and sanity testing Regression testing Acceptance testing Alpha testing Beta testing Functional vs non-functional testing Destructive testing Software performance testing Usability testing Accessibility testing Security testing Internationalization and localization Development testing A/B testing
- 10. Prueba unitaria
- 11. Pruebas unitarias A unit test is a piece of a code (usually a method) that invokes another piece of code and checks the correctness of some assumptions afterward. If the assumptions turn out to be wrong, the unit test has failed. A “unit” is a method or function. Unit test definition – The art of unit testing Roy Osherove – Manning Publications co.
- 12. Caracteristicas: FIRST • Fast • Isolated • Repeatable • Self-validating • Timely
- 13. Caracteristicas: SECOND • Profesional • Unitario • Automatizable • No usa recursos
- 14. Estructura: Triple Cuadruple A • Assume • Arrange • Act • Assert
- 15. Codigo
- 16. Si un metodo o funcion es una unidad tengo que desglosarlos al maximo vs.
- 18. ¿Puedo escribir mejores unit tests?
- 19. Puedes escribir mejor codigo
- 22. Patrones • Inversion of Control • Abstract Factory
- 23. Test doubles
- 24. Test doubles • Dummies • Fakes • Stubs • Spies • Mocks xUnit Test Patterns Gerrard Meszaros – Hardcover
- 25. jMock
- 26. JSmockito
- 27. Evitar uso de estaticos o singletons
- 29. Simplifica los constructores • No uses `new` • No asignes algo que no sean atributos • No uses `Initializer` • No uses condicionales o bucles
- 30. Test positivo y negativo
- 31. Ventajas de unit testing • Encontrar bugs pronto • Red de seguridad • Documentacion • Mejor diseno
- 32. Limitaciones de unit testing • No detectan problemas de: Integracion, performance, … • No todo puede ser testeado con facilidad Multi-threading, algoritmos no deterministas
- 33. Tecnicas • TDD • ATDD • BDD
- 34. Metricas de codigo • Code Coverage • Cyclomatic Complexity
Notas del editor
- Tokiota es una empresa joven que a lo largo de su año de vida ha conseguido un gran reconocimiento como especialistas en tecnologías Microsoft. Somos goldpartners en movilidad (desarrollo de Windows pone y Windows Store), pertenecemos al azurecircle y como partner preferente de Microsoft estamos especializados en:Arquitectura de softwareSoluciones CloudInfraestructuraDesarrollo en tecnologías Microsoft
- Una prueba de software es una investigación que se lleva a cabo con el fin de proporcionar a los stakeholders información sobre la calidad del mismo. No tienen por qué basarse solo en código. Nos pueden aportar en adición datos sobre performance y reporte de errores o defectos en el software.
- Una prueba de software es una investigación que se lleva a cabo con el fin de proporcionar a los stakeholders información sobre la calidad del mismo. No tienen por qué basarse solo en código. Nos pueden aportar en adición datos sobre performance y reporte de errores o defectos en el software.
- Métodos de testing:White Box: pruebas de las estructuras internas de trabajo de un programa. El tester especifica unas entradas que se ejecutarán a lo largo de diferentes ámbitos del código y definirá unas salidas apropiadas. Este método se aplica en las pruebas unitarias, de integración y del sistema.Black Box: son pruebas del comportamiento externo de una aplicación. Sin tener en cuenta ni conocimiento de como se han implementado internamente. Pueden ser aplicados a todos los niveles de testing: unitarios, integración, sistema y aceptación. Un ejemplo y subtipo de este método de testing son los visuales o de UI.Grey Box: son pruebas de tipo black box en las que hay que tener cierto conocimiento de la implementación interna, pero no de todo el código fuente. (ejemplo test de carga de wke).Niveles de testing:Unitarios: verifica una funcionalidad de una sección del código fuente específica. Generalmente utilizados por los desarrolladores usando el método de White box.Integración: verifican que los diferentes componentes, interfaces y artefactos de un sistema trabajan bien entre ellos.Sistema: se usan sobre un sistema totalmente integrado y desplegado. Y validan que el sistema cumple los requisitos deseados y que el software se comporta correctamente dentro de este.Aceptación: se usan sobre el aplicativo terminado, para validar que realmente realiza las operaciones como se espera.Tipos de testing:Hay muchos, en dependencia de cual es el objetivo del test que estamos realizando. Una prueba unitaria puede ser de cualquiera de estos tipos….
- Métodos de testing:White Box: pruebas de las estructuras internas de trabajo de un programa. El tester especifica unas entradas que se ejecutarán a lo largo de diferentes ámbitos del código y definirá unas salidas apropiadas. Este método se aplica en las pruebas unitarias, de integración y del sistema.Black Box: son pruebas del comportamiento externo de una aplicación. Sin tener en cuenta ni conocimiento de como se han implementado internamente. Pueden ser aplicados a todos los niveles de testing: unitarios, integración, sistema y aceptación. Un ejemplo y subtipo de este método de testing son los visuales o de UI.Grey Box: son pruebas de tipo black box en las que hay que tener cierto conocimiento de la implementación interna, pero no de todo el código fuente. (ejemplo test de carga de wke).Niveles de testing:Unitarios: verifica una funcionalidad de una sección del código fuente específica. Generalmente utilizados por los desarrolladores usando el método de White box.Integración: verifican que los diferentes componentes, interfaces y artefactos de un sistema trabajan bien entre ellos.Sistema: se usan sobre un sistema totalmente integrado y desplegado. Y validan que el sistema cumple los requisitos deseados y que el software se comporta correctamente dentro de este.Aceptación: se usan sobre el aplicativo terminado, para validar que realmente realiza las operaciones como se espera.Tipos de testing:Hay muchos, en dependencia de cual es el objetivo del test que estamos realizando. Una prueba unitaria puede ser de cualquiera de estos tipos….
- Métodos de testing:White Box: pruebas de las estructuras internas de trabajo de un programa. El tester especifica unas entradas que se ejecutarán a lo largo de diferentes ámbitos del código y definirá unas salidas apropiadas. Este método se aplica en las pruebas unitarias, de integración y del sistema.Black Box: son pruebas del comportamiento externo de una aplicación. Sin tener en cuenta ni conocimiento de como se han implementado internamente. Pueden ser aplicados a todos los niveles de testing: unitarios, integración, sistema y aceptación. Un ejemplo y subtipo de este método de testing son los visuales o de UI.Grey Box: son pruebas de tipo black box en las que hay que tener cierto conocimiento de la implementación interna, pero no de todo el código fuente. (ejemplo test de carga de wke).Niveles de testing:Unitarios: verifica una funcionalidad de una sección del código fuente específica. Generalmente utilizados por los desarrolladores usando el método de White box.Integración: verifican que los diferentes componentes, interfaces y artefactos de un sistema trabajan bien entre ellos.Sistema: se usan sobre un sistema totalmente integrado y desplegado. Y validan que el sistema cumple los requisitos deseados y que el software se comporta correctamente dentro de este.Aceptación: se usan sobre el aplicativo terminado, para validar que realmente realiza las operaciones como se espera.Tipos de testing:Hay muchos, en dependencia de cual es el objetivo del test que estamos realizando. Una prueba unitaria puede ser de cualquiera de estos tipos….
- Una prueba unitaria es una pieza de código (generalmente un método) que invoca a otra pieza de código y comprueba después la exactitud de ciertos supuestos. Si alguno de estos supuestos termina siendo erróneo, la prueba unitaria ha fallado.Una “unidad” es un método o una función.
- Fast: Rápidos. Tenemos que ser capaces de ejecutar cientos de pruebas en un solo segundo.Isolated: Una prueba unitaria tiene que estar aislada del resto de pruebas y del resto del código que no se quiere probar.Repeatable: Tenemos que poder repetir una prueba tantas veces como sea necesario sin que esto afecte al resultado. Self-validating: Una prueba unitaria devuelve si se ha pasado o si ha fallado. No tiene que dejar cosas al aire para la interpretación.Timely: Estamos acostumbrados a escribir las pruebas justo después de hacer el código que queremos probar. Y esas pruebas las realiza el mismo desarrollador. Lo cierto es que hacerlas antes de codificar o que las escriba otra persona después, aportará valor. Un unit test tiene que ser escrito en el momento oportuno.
- Profesional: es parte de tu código, refactorizalo, documentalo si es que documentas,…. Y básicamente mantenlo como la pieza fundamental de tu desarrollo.Unitario: es muy redundante decirlo, pero solo hay que probar una cosa por prueba. Un aspecto básico del total del código fuente.Automatizable: un test unitario no debería depender de una persona para que lo ejecute y lea los resultados. Deberíamos automatizarlo de alguna forma. En este sentido existen muchas frameworks que nos ayudarán con esta la tarea.No usa recursos: no accede a disco, ni a base de datos, ni abre conexiones remotas.
- Suposiciones: asumir condiciones previas sobre las entradas de pruebaOrganizar: establecer el contexto de la unidad bajo pruebaActuar: ejecutar la unidad bajo prueba, capturando cualquier estado resultanteAfirmar: verificar el comportamiento a través de afirmaciones (assertions)
- Are youfuckingkidding me?
- Lo que puedes hacer es escribir mejor código, código “testeable”.Vamos a ver algunos truquillos:
- Testdoubles es el nombre genérico que recibe la técnica de reemplazar un objeto del sistema existente por otro, solo con fines de prueba. Estos objetos ayudarán a que nuestras pruebas unitarias solo prueben una cosa y no las demás.Tipos:Dummy (maniquí): son objetos que se van pasando por el test, pero que en realidad no se usan. Se suelen usar para almacenar datos “vacíos”.Fake (falso): es un objeto que contiene lógica que funciona. Pero esta lógica no sirve para producción. Un ejemplo sería la gestión de una base de datos en memoria, para no crear sockets ni tocar archivos.Stubs (esbozo): proporcionan respuestas enlatadas a las llamadas realizadas durante la prueba, por lo general no responden en absoluto a nada fuera de lo que está programado en la prueba.Spies (espias): son stubs que además de proporcionar esas llamadas específicas, también guardan una estadística de las mismas. Por ejemplo cuantas veces ha sido llamado un método.Mocks (simulacro): son objetos pre-programados con las expectativas de las llamadas que van a recibir. Pueden lanzar excepciones cuando reciben llamadas no admitidas. Y al final se verifica que se han realizado todas las llamadas que se esperaban.
- Testdoubles es el nombre genérico que recibe la técnica de reemplazar un objeto del sistema existente por otro, solo con fines de prueba. Estos objetos ayudarán a que nuestras pruebas unitarias solo prueben una cosa y no las demás.Tipos:Dummy (maniquí): son objetos que se van pasando por el test, pero que en realidad no se usan. Se suelen usar para almacenar datos “vacíos”.Fake (falso): es un objeto que contiene lógica que funciona. Pero esta lógica no sirve para producción. Un ejemplo sería la gestión de una base de datos en memoria, para no crear sockets ni tocar archivos.Stubs (esbozo): proporcionan respuestas enlatadas a las llamadas realizadas durante la prueba, por lo general no responden en absoluto a nada fuera de lo que está programado en la prueba.Spies (espias): son stubs que además de proporcionar esas llamadas específicas, también guardan una estadística de las mismas. Por ejemplo cuantas veces ha sido llamado un método.Mocks (simulacro): son objetos pre-programados con las expectativas de las llamadas que van a recibir. Pueden lanzar excepciones cuando reciben llamadas no admitidas. Y al final se verifica que se han realizado todas las llamadas que se esperaban.
- Simplificar los constructores de los objetos. No meter lógica:Si dentro de un constructor tienes que usar la palabra “new” para instanciar otro objeto, es que tienes un problema.No asignes valores que no sean atributos de la propia clase. Es decir, mantén la cohesión.No usar métodos como “Initializer” o algo así, aunque sean más fáciles de testear que el propio constructor.Y por supuesto no se debería insertar ninguna lógica o flujo dentro de un constructor, así que ni condiciones ni bucles.
- Siempre solemos probar el caso afirmativo de un problema. Cuando un test tiene que dar este resultado. Una buena práctica es también probar el caso de que no lo dé. Es decir, si hago una operación obtengo este resultado, pero es interesante saber que si no la hago exactamente igual, no voy a obtener ese mismo resultado.
- - TDD: escribir pruebas antes que el código que las resuelvaATDD: es similar a TDD, pero TDD se basa en pruebas unitarias y ATDD en pruebas de aceptaciónBDD: similar a TDD pero en lugar de unittests se crean specs. Las specs se centran en el comportamiento antes que en la implementación.