Your SlideShare is downloading. ×
AutomateTesting<br />Email: snahider@gmail.com<br />Blog: http://snahider.blogspot.com<br />Twitter: @snahider<br />Angel ...
Tipos de Test<br />Es una nomenclatura caótica y no existe una sola categoría.<br />Alcance: Unidades, Componentes, Sistem...
Sistema<br />Tipos de pruebas según su alcance<br />+<br />Integración<br />Unitarios<br />-<br />Alcance<br />
Unit TestingAutomate Testing<br />Email: snahider@gmail.com<br />Blog: http://snahider.blogspot.com<br />Twitter: @snahide...
Pruebas Unitarias<br />No pruebes el auto completo si aún no sabes si funcionan los engranes.<br />
Prueba Unitaria (Micro Test)<br />Una prueba unitaria es un fragmento automatizado de código, escrito y mantenido por los ...
Nuestro Objetivo<br />Probar las unidades lógicas  o caminos que existen dentro de una clase.<br />
Independencia (Aislamiento)<br />Se realizan de manera separada al resto de la aplicación, de sus dependencias y no accede...
No depende de archivos de configuración.
No ejercita la clase y todas sus dependencias en simultáneo.</li></li></ul><li>Demostración<br />Veremos el funcionamiento...
Beneficios de las pruebas unitarias<br />Realizar cambios es mucho más sencillo.<br />Nuevas funcionalidades no rompen las...
UnitTesting Frameworks<br />Frameworks que nos proveen todos los mecanismos necesarios para ejecutar la lógica específica ...
Java:   JUnit, TestNG, Easyb, JTiger …..
Ruby: Test::Unit, Rspec, Shoulda …..</li></li></ul><li>EjercicioCrear test unitarios para una clase<br />Crear los test un...
Organización de un Proyecto<br />Mantener las pruebas separadas del código de producción.<br />Una clase de prueba por cad...
Organización de un Proyecto<br />Mantener las pruebas separadas del código de producción.<br />Una clase de prueba por cad...
Creando una prueba<br />Las pruebas se encuentran dentro de una clase marcada con un atributo<br />Las pruebas son métodos...
Creando una prueba<br />Las pruebas se encuentran dentro de una clase.<br />Las pruebas son métodos marcados con una anota...
Asserts<br />Métodos a través de los cuales podemos verificar el éxito o fracaso de nuestras pruebas.<br />Múltiples sobre...
Ejecutando las pruebas<br /><ul><li>Utilizando la barra de herramientas de pruebas.
Hot Keys:
Ejecutar las pruebas dentro del contexto actual (Ctrl+R,T)
Ejecutar todas las pruebas (Ctrl+R,A)</li></li></ul><li>Ejecutando las pruebas<br /><ul><li>Utilizando la barra de herrami...
Menú contextual sobre la clase/package/proyecto y seleccionar "RunAs -> Junit Test".
Hot Keys: "Run As JUnit Test" (Alt+Shift+X,T)</li></li></ul><li>Nombre de las Pruebas<br />Debe tener las siguientes carac...
Incluir las entradas/estado inicial y el resultado esperado para dichas entradas.</li></ul>[NombreMétodo_EstadoEnPrueba_Co...
Estructura de una prueba<br />Creamos todas las precondiciones y entradas necesarias.<br />ARRANGE<br />Realizamos la acci...
Nuestra segunda Prueba<br />Realizar la prueba unitaria que verifique : <br />«El Stack no se encuentra vacío si contiene ...
Don't repeat yourself<br />Para aumentar nuestra productividad utilizaremos un snippet para las pruebas<br /><ul><li>Exten...
Menu: File->New->File
Categoría SnippetDesigner: Seleccionar CodeSnippet</li></li></ul><li>Don't repeat yourself<br />Para aumentar nuestra prod...
Categoría Java->Editor->Templates
Click en el botón New..</li></li></ul><li>EjercicioCompletar las siguientes pruebas<br />Al ingresar y sacar un elemento, ...
Set Up y TearDown<br />Métodos que nos permiten crear y limpiar datos que son comunes a todas las pruebas. <br />Set Up Fo...
Tear Down (Destructor de las pruebas): Limpiar datos que afecten la ejecución entre prueba y prueba.</li></li></ul><li>Set...
Ejemplos Set Up y Tear Down<br />Unit Test<br />Test Fixtures<br />
Ejemplos Set Up y Tear Down<br />Unit Test<br />Test Fixtures<br />
Probando Excepciones<br />Forma Tradicional<br />Utilizando Atributos<br />
Probando Excepciones<br />Forma Tradicional<br />Utilizando Atributos<br />ExceptedException Rule<br />
EjercicioProbar una Excepción y utilizar un Set Up<br />Crear una prueba para verificar que al obtener un elemento y el st...
Propiedades de una prueba unitaria<br />Fast: Unos cuantos milisegundos en ejecutarse.<br />Independent: Enfocarse en una ...
Test DoublesAutomate Testing<br />Email: snahider@gmail.com<br />Blog: http://snahider.blogspot.com<br />Twitter: @snahide...
Testeabilidad<br />La testeabilidad es un atributo de calidad del códigoque permite que las pruebas automatizadas sean rea...
EjercicioRevisar las pruebas realizadas a un código "no testeable"<br />¿Cuál es el problema del código de producción?"Es ...
¿Cuál es el problema?<br />Las clases de alto nivel no deben depender directamente de clases de bajo nivel sino de abstrac...
Inversión de Dependencias<br />Las clases de alto nivel no deben depender directamente de clases de bajo nivel sino de abs...
Inyección de Dependencias<br />Proveer las instancias de las clases dependencia desde fuera del ámbito de la clase.<br />O...
EjercicioRefactorizar el código para mejorar su testeabilidad.<br />Utilizar inyección e inversión de dependencias para de...
¿ Cuál es el siguiente paso ?<br />Ahora que las clases no dependen de una implementación específica, debemos hacer que lo...
EjercicioModificar los test para realizar pruebas unitaras a clases con dependencias.<br />Crear una nueva clase más simpl...
El Mundo Real<br />BD<br />Other<br />Class<br />Other<br />Class<br />Act<br />Other<br />Class<br />Test<br />ClassUnder...
¿Cuál es el problema?<br />Responsabilidades de la clase<br />Creación de jerarquía de objetos<br />Lógica de Negocios<br />
Encontrando la solución<br />Responsabilidades de una clase externa<br />Responsabilidades de la clase<br />Creación de je...
Encontrando la solución<br />Simple<br />Class<br />Act<br />Simple<br />Class<br />Test<br />ClassUnder Test<br />Assert<...
Test Doubles<br />Test Double<br />Test Double<br />Son todos aquellos objetos que han sido creados para reemplazar a los ...
IsolationMockingFrameworks<br /><ul><li>Crear test doubles de manera más simple, rápida y sin errores.
Evitar escribir código repetitivo.
.NET:  Moq,RhinoMock, Typemock
Java:  Mockito, EasyMock, Jmock
Ruby: RSpecBuilt-in, Mocha</li></li></ul><li>Tipos de Test Doubles<br />Stubs<br />Mocks<br />Dummies<br />Fakes<br />
Test Doubles: Stubs<br />
Test Doubles: Stubs<br /><ul><li>Reemplaza una dependencia existente en el sistema de tal manera que el test no tenga que ...
La prueba tiene el control sobre este test double, por lo que puede indicarle respuestas predefinidas a ciertas llamadas.
Son utilizados cuando nuestro método en prueba depende de un valor que es retornado por otro componente.</li></li></ul><li...
StateTesting VS InteractionTesting<br />StateTesting<br />(ResultDriven) Verificamos si un resultado final es el esperado....
Test Doubles: Mocks<br />Nos permiten verificar si un objeto ha enviado o recibido un determinado mensaje de otro objeto. ...
Test Doubles : Mocks<br /><ul><li>No devuelve resultados predefinidos, sino está pendiente que el objeto en prueba interac...
El Assert ya no se ejecuta sobre la clase en prueba sino sobre el mock.
Lo usamos para probar acciones que no pueden ser observadas a través de la API pública de la clase que se está probando. <...
Como los diferenciamos fácilmente<br />Stub: El Test Double que permite que el test pueda terminar su ejecución.<br />Mock...
Explorando el API de Moq<br /><ul><li>Creando un Test Double
Stubbing
ArgumentMatchers
Stubbingcon excepciones
Verificar comportamiento</li></li></ul><li>Explorando el API de Mockito<br /><ul><li>Creando un Test Double
Stubbing
ArgumentMatchers
Stubbingcon excepciones
Verificar comportamiento</li></li></ul><li>Otros Test Doubles<br />Dummy<br />Objetos que se encuentran instanciados pero ...
EjercicioRealizar pruebas unitarias a clases con dependencias<br />IsEnabled debe retornar verdadero si el nivel del mensa...
CodeCoverage<br />Medida de calidad del software.<br />Valor cuantitativo que indica el número de áreas de nuestra aplicac...
Java:  Clover, EMMA, Cobertura
Ruby: RCov</li></li></ul><li>¿ Tenemos que lograr 100%  de Coverage ?<br />El coverage no nos dice si hemos cubierto los c...
Valor proporcional a la complejidad ciclomática.</li></ul>¿ Será suficiente pasar una única vez por un camino?<br />
Costo vs Beneficiode las pruebas unitarias<br />Algoritmos<br />Código complicado – Necesita refactorizar<br />Alto<br />B...
EjercicioMedir el CodeCoverage en una aplicación.<br />Medir el codecoverage utilizando las herramientas integradas dentro...
¿ Como escribimos código que sea difícil de probar ?<br />
«No hay ningún secreto en cómo escribir los tests,solo hay secretos en cómo escribir código testeable.»<br />MiskoHevery<b...
Como podemos mejorar la testeabilidad<br /><ul><li>Aislar las dependencias e inyectarlas.
Upcoming SlideShare
Loading in...5
×

Pruebas Automatizadas

6,094

Published on

Preview de los slides para el curso "Automate Testing"

Los slides completos del curso "Automate Testing" para .NET se encuentran en
http://www.slideshare.net/snahider/automate-testing-net

Published in: Technology, Business
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,094
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

Transcript of "Pruebas Automatizadas"

  1. 1. AutomateTesting<br />Email: snahider@gmail.com<br />Blog: http://snahider.blogspot.com<br />Twitter: @snahider<br />Angel Núñez Salazar<br />
  2. 2. Tipos de Test<br />Es una nomenclatura caótica y no existe una sola categoría.<br />Alcance: Unidades, Componentes, Sistemas<br />Etapa: Integración, aceptación, regresión<br />Enfoque: Performance, funcionales<br />Visibilidad: White / Black box<br />El tipo de test se convierte en un atributo.<br />
  3. 3. Sistema<br />Tipos de pruebas según su alcance<br />+<br />Integración<br />Unitarios<br />-<br />Alcance<br />
  4. 4. Unit TestingAutomate Testing<br />Email: snahider@gmail.com<br />Blog: http://snahider.blogspot.com<br />Twitter: @snahider<br />Angel Núñez Salazar<br />
  5. 5. Pruebas Unitarias<br />No pruebes el auto completo si aún no sabes si funcionan los engranes.<br />
  6. 6. Prueba Unitaria (Micro Test)<br />Una prueba unitaria es un fragmento automatizado de código, escrito y mantenido por los desarrolladores, que invoca un método o función para verificar ciertas suposiciones sobre el comportamiento de una única clase.<br />
  7. 7. Nuestro Objetivo<br />Probar las unidades lógicas o caminos que existen dentro de una clase.<br />
  8. 8. Independencia (Aislamiento)<br />Se realizan de manera separada al resto de la aplicación, de sus dependencias y no acceden a recursos del sistema.<br /><ul><li>No se comunica con la base de datos.
  9. 9. No depende de archivos de configuración.
  10. 10. No ejercita la clase y todas sus dependencias en simultáneo.</li></li></ul><li>Demostración<br />Veremos el funcionamiento de las pruebas unitarias dentro de la aplicación open sourceCodeCampServer<br />
  11. 11. Beneficios de las pruebas unitarias<br />Realizar cambios es mucho más sencillo.<br />Nuevas funcionalidades no rompen las existentes.<br />El proceso de desarrollo se vuelve más flexible.<br />Los problemas se encuentran temprano en el ciclo de desarrollo.<br />El diseño mejora debido a que el código es forzado a ser más desacoplado y testeable.<br />Código que funciona ahora, funcionará en el futuro.<br />La necesidad de pruebas manuales se reduce.<br />
  12. 12. UnitTesting Frameworks<br />Frameworks que nos proveen todos los mecanismos necesarios para ejecutar la lógica específica a nuestra prueba sin preocuparnos por la infraestructura necesaria.<br /><ul><li>.NET: NUnit, MSTest, XUnit.net, Mbunit…..
  13. 13. Java: JUnit, TestNG, Easyb, JTiger …..
  14. 14. Ruby: Test::Unit, Rspec, Shoulda …..</li></li></ul><li>EjercicioCrear test unitarios para una clase<br />Crear los test unitarios para una lista del tipo pila "Stack" (Last In - FirstOut)<br />
  15. 15. Organización de un Proyecto<br />Mantener las pruebas separadas del código de producción.<br />Una clase de prueba por cada clase de producción. (Test Fixture per class)<br />Proyecto de Producción<br />Proyecto con las pruebas<br />Referencia al proyecto de producción<br />Test Framework<br />
  16. 16. Organización de un Proyecto<br />Mantener las pruebas separadas del código de producción.<br />Una clase de prueba por cada clase de producción. (Test Fixture per class)<br />Directorio de producción<br />Directorio con las pruebas<br />Test Framework<br />
  17. 17. Creando una prueba<br />Las pruebas se encuentran dentro de una clase marcada con un atributo<br />Las pruebas son métodos marcados con un atributo<br />La prueba pasa al menos que el assert falle o se produzca un error<br />
  18. 18. Creando una prueba<br />Las pruebas se encuentran dentro de una clase.<br />Las pruebas son métodos marcados con una anotación.<br />La prueba pasa al menos que el assert falle o se produzca un error<br />
  19. 19. Asserts<br />Métodos a través de los cuales podemos verificar el éxito o fracaso de nuestras pruebas.<br />Múltiples sobre escrituras para verificar diversos casos.<br />Si la verificación falla, nos devuelven un mensaje con información para poder solucionar el problema.<br />Assert.AreEqualfailed. Expected: <2>, Actual:<0><br />Podemos agregar mensajes adicionales para que sean mostrados en caso el test falle.<br />Assert.AreEqualfailed. Expected: <2>, Actual: <0>. 1+1 deberíaser 2<br />
  20. 20. Ejecutando las pruebas<br /><ul><li>Utilizando la barra de herramientas de pruebas.
  21. 21. Hot Keys:
  22. 22. Ejecutar las pruebas dentro del contexto actual (Ctrl+R,T)
  23. 23. Ejecutar todas las pruebas (Ctrl+R,A)</li></li></ul><li>Ejecutando las pruebas<br /><ul><li>Utilizando la barra de herramientas.
  24. 24. Menú contextual sobre la clase/package/proyecto y seleccionar "RunAs -> Junit Test".
  25. 25. Hot Keys: "Run As JUnit Test" (Alt+Shift+X,T)</li></li></ul><li>Nombre de las Pruebas<br />Debe tener las siguientes características:<br /><ul><li>Expresar un requerimiento específico.
  26. 26. Incluir las entradas/estado inicial y el resultado esperado para dichas entradas.</li></ul>[NombreMétodo_EstadoEnPrueba_ComportamientoEsperado]<br />Las convenciones nos permiten contar con reglas o plantillas que todo el equipo puede seguir para lograr un rápido entendimiento acerca de las pruebas.<br />
  27. 27. Estructura de una prueba<br />Creamos todas las precondiciones y entradas necesarias.<br />ARRANGE<br />Realizamos la acción del objeto que estamos probando.<br />ACT<br />ASSERT<br />Verificamos los resultados esperados.<br />
  28. 28. Nuestra segunda Prueba<br />Realizar la prueba unitaria que verifique : <br />«El Stack no se encuentra vacío si contiene un elemento»<br />
  29. 29. Don't repeat yourself<br />Para aumentar nuestra productividad utilizaremos un snippet para las pruebas<br /><ul><li>Extensión Manager: Instalar SnippetDesigner
  30. 30. Menu: File->New->File
  31. 31. Categoría SnippetDesigner: Seleccionar CodeSnippet</li></li></ul><li>Don't repeat yourself<br />Para aumentar nuestra productividad utilizaremos un snippet para las pruebas<br /><ul><li>Menu: Window->Preferences
  32. 32. Categoría Java->Editor->Templates
  33. 33. Click en el botón New..</li></li></ul><li>EjercicioCompletar las siguientes pruebas<br />Al ingresar y sacar un elemento, el stack está vacío.<br />Al ingresar dos y sacar uno, el stack no está vacio.<br />Al ingresar y sacar un elemento, el elemento debe ser igual al ingresado.<br />Al ingresar dos y obtener un elemento, el elemento debe ser igual al segundo ingresado<br />Al ingresar dos y obtener dos, el segundo elemento obtenido es igual al primero que se ha ingresado.<br />
  34. 34. Set Up y TearDown<br />Métodos que nos permiten crear y limpiar datos que son comunes a todas las pruebas. <br />Set Up For Unit Test<br />Unit Test<br />Tear Down For Unit Test<br /><ul><li>Set Up (Constructor de las pruebas): Inicializar datos que son comunes a todos las pruebas.
  35. 35. Tear Down (Destructor de las pruebas): Limpiar datos que afecten la ejecución entre prueba y prueba.</li></li></ul><li>Set Up y Tear Down en Test Fixtures<br />Establecer un estado una única vez al inicio de todos los test y una única vez al finalizar todos.<br />Set Up For Test Fixture<br />Set Up For Unit Test<br />Unit Test<br />Tear Down For Unit Test<br />Tear Down For Test Fixture<br />
  36. 36. Ejemplos Set Up y Tear Down<br />Unit Test<br />Test Fixtures<br />
  37. 37. Ejemplos Set Up y Tear Down<br />Unit Test<br />Test Fixtures<br />
  38. 38. Probando Excepciones<br />Forma Tradicional<br />Utilizando Atributos<br />
  39. 39. Probando Excepciones<br />Forma Tradicional<br />Utilizando Atributos<br />ExceptedException Rule<br />
  40. 40. EjercicioProbar una Excepción y utilizar un Set Up<br />Crear una prueba para verificar que al obtener un elemento y el stack se encuentre vacío, se lance una excepción.<br />Crear un método SetUp para remover el código duplicado de los test.<br />
  41. 41. Propiedades de una prueba unitaria<br />Fast: Unos cuantos milisegundos en ejecutarse.<br />Independent: Enfocarse en una única unidad de código.<br />Repeatable: Ejecutarse de manera repetitiva sin intervención.<br />Self-validating: Sin necesidad de reexaminar los resultados.<br />Transparent: Comunicar claramente lo que se busca probar.<br />
  42. 42. Test DoublesAutomate Testing<br />Email: snahider@gmail.com<br />Blog: http://snahider.blogspot.com<br />Twitter: @snahider<br />Angel Núñez Salazar<br />
  43. 43. Testeabilidad<br />La testeabilidad es un atributo de calidad del códigoque permite que las pruebas automatizadas sean realizadas de manera fácil y efectiva.<br />La testeabilidad por lo general es señal de un buen diseño.<br />Si queremos que un código sea testeable, debemos escribir pensando en la testeabilidad.<br />No cualquier código puede ser probado de manera unitaria.<br />
  44. 44. EjercicioRevisar las pruebas realizadas a un código "no testeable"<br />¿Cuál es el problema del código de producción?"Es un código muy acoplado"<br />
  45. 45. ¿Cuál es el problema?<br />Las clases de alto nivel no deben depender directamente de clases de bajo nivel sino de abstracciones de estas clases.<br />
  46. 46. Inversión de Dependencias<br />Las clases de alto nivel no deben depender directamente de clases de bajo nivel sino de abstracciones de estas clases.<br />
  47. 47. Inyección de Dependencias<br />Proveer las instancias de las clases dependencia desde fuera del ámbito de la clase.<br />Outside<br />
  48. 48. EjercicioRefactorizar el código para mejorar su testeabilidad.<br />Utilizar inyección e inversión de dependencias para desacoplar el código.<br />
  49. 49. ¿ Cuál es el siguiente paso ?<br />Ahora que las clases no dependen de una implementación específica, debemos hacer que los test decidan cual es la dependencia a usar y la inyecten a la clase que se está probando.<br />
  50. 50. EjercicioModificar los test para realizar pruebas unitaras a clases con dependencias.<br />Crear una nueva clase más simple que reemplace a la original solo para los propósitos de las pruebas.<br />
  51. 51. El Mundo Real<br />BD<br />Other<br />Class<br />Other<br />Class<br />Act<br />Other<br />Class<br />Test<br />ClassUnder Test<br />FileSystem<br />Assert<br />Other<br />Class<br />Other<br />Class<br />
  52. 52. ¿Cuál es el problema?<br />Responsabilidades de la clase<br />Creación de jerarquía de objetos<br />Lógica de Negocios<br />
  53. 53. Encontrando la solución<br />Responsabilidades de una clase externa<br />Responsabilidades de la clase<br />Creación de jerarquía de objetos<br />Lógica de Negocios<br />
  54. 54. Encontrando la solución<br />Simple<br />Class<br />Act<br />Simple<br />Class<br />Test<br />ClassUnder Test<br />Assert<br />Simple<br />Class<br />
  55. 55. Test Doubles<br />Test Double<br />Test Double<br />Son todos aquellos objetos que han sido creados para reemplazar a los objetos reales con el propósito de hacer pruebas<br />
  56. 56. IsolationMockingFrameworks<br /><ul><li>Crear test doubles de manera más simple, rápida y sin errores.
  57. 57. Evitar escribir código repetitivo.
  58. 58. .NET: Moq,RhinoMock, Typemock
  59. 59. Java: Mockito, EasyMock, Jmock
  60. 60. Ruby: RSpecBuilt-in, Mocha</li></li></ul><li>Tipos de Test Doubles<br />Stubs<br />Mocks<br />Dummies<br />Fakes<br />
  61. 61. Test Doubles: Stubs<br />
  62. 62. Test Doubles: Stubs<br /><ul><li>Reemplaza una dependencia existente en el sistema de tal manera que el test no tenga que lidiar directamente con esa dependencia.
  63. 63. La prueba tiene el control sobre este test double, por lo que puede indicarle respuestas predefinidas a ciertas llamadas.
  64. 64. Son utilizados cuando nuestro método en prueba depende de un valor que es retornado por otro componente.</li></li></ul><li>EjercicioUtilizar un stub para realizar pruebas unitarias<br />Revisar las pruebas anteriormente creadas e identificar el stub.<br />Utilizar una framework para reemplazar el stub creado de forma manual.<br />
  65. 65. StateTesting VS InteractionTesting<br />StateTesting<br />(ResultDriven) Verificamos si un resultado final es el esperado.Ejm: que una propiedad ha cambiado su valor.<br />InterationTesting<br />(ActionDriven)Verificamos si una determinada acción se ha producido. Ejm: que se ha enviado un mensaje hacia otro objeto.<br />
  66. 66. Test Doubles: Mocks<br />Nos permiten verificar si un objeto ha enviado o recibido un determinado mensaje de otro objeto. (Si un objeto ha interactuado correctamente con otro objeto)<br />
  67. 67. Test Doubles : Mocks<br /><ul><li>No devuelve resultados predefinidos, sino está pendiente que el objeto en prueba interactúe con el de una manera esperada.
  68. 68. El Assert ya no se ejecuta sobre la clase en prueba sino sobre el mock.
  69. 69. Lo usamos para probar acciones que no pueden ser observadas a través de la API pública de la clase que se está probando. </li></li></ul><li>EjercicioUtilizar un mock para realizar pruebas unitarias<br />Revisar las pruebas anteriormente creadas e identificar el mock.<br />Utilizar una framework para reemplazar el mock creado de forma manual.<br />
  70. 70. Como los diferenciamos fácilmente<br />Stub: El Test Double que permite que el test pueda terminar su ejecución.<br />Mock: El Test Double sobre el cuál se realiza un aserto.<br />
  71. 71. Explorando el API de Moq<br /><ul><li>Creando un Test Double
  72. 72. Stubbing
  73. 73. ArgumentMatchers
  74. 74. Stubbingcon excepciones
  75. 75. Verificar comportamiento</li></li></ul><li>Explorando el API de Mockito<br /><ul><li>Creando un Test Double
  76. 76. Stubbing
  77. 77. ArgumentMatchers
  78. 78. Stubbingcon excepciones
  79. 79. Verificar comportamiento</li></li></ul><li>Otros Test Doubles<br />Dummy<br />Objetos que se encuentran instanciados pero nunca se utilizan, usualmente para llenar una lista de parámetros.<br />Fake<br />Reemplazan al real por razones diferentes a verificar salidas o comportamientos. Tienen la misma funcionalidad pero más sencilla<br />
  80. 80. EjercicioRealizar pruebas unitarias a clases con dependencias<br />IsEnabled debe retornar verdadero si el nivel del mensaje está antes al nivel del logger.<br />IsEnabled debe retornar falso si el nivel del mensaje está después al nivel del logger.<br />Writedebe enviar un email al administrador si el nivel es ERROR.<br />Write debe escribir en el appender si el logger está habilitado.<br />
  81. 81. CodeCoverage<br />Medida de calidad del software.<br />Valor cuantitativo que indica el número de áreas de nuestra aplicación que han sido ejercitadas por un conjunto de casos de prueba.<br /><ul><li>.NET: NCover, PartCover, Visual Studio
  82. 82. Java: Clover, EMMA, Cobertura
  83. 83. Ruby: RCov</li></li></ul><li>¿ Tenemos que lograr 100% de Coverage ?<br />El coverage no nos dice si hemos cubierto los caminos más riesgosos o si los caminos cubiertos han valido el esfuerzo. <br />Lograr un balance costo - beneficio.<br />Cuál es el valor adecuado no es una respuesta simple y depende de muchos factores.<br /><ul><li>Usualmente 80% es un buen número.
  84. 84. Valor proporcional a la complejidad ciclomática.</li></ul>¿ Será suficiente pasar una única vez por un camino?<br />
  85. 85. Costo vs Beneficiode las pruebas unitarias<br />Algoritmos<br />Código complicado – Necesita refactorizar<br />Alto<br />Beneficio de la prueba<br />≈ Código no obvio<br />Código Trivial<br />Coordinadores<br />Bajo<br />Bajo<br />Alto<br />Costo de la prueba<br />≈ Número de dependencias<br />Steven Sanderson Blog: http://bit.ly/lNGDjq<br />
  86. 86. EjercicioMedir el CodeCoverage en una aplicación.<br />Medir el codecoverage utilizando las herramientas integradas dentro de los IDES.<br />Analizar los resultados e identificar las áreas que no han sido ejercidas por ninguna prueba.<br />
  87. 87. ¿ Como escribimos código que sea difícil de probar ?<br />
  88. 88. «No hay ningún secreto en cómo escribir los tests,solo hay secretos en cómo escribir código testeable.»<br />MiskoHevery<br />
  89. 89. Como podemos mejorar la testeabilidad<br /><ul><li>Aislar las dependencias e inyectarlas.
  90. 90. No realizar trabajo en el constructor.
  91. 91. Preferir la composición sobre la herencia.
  92. 92. Evitar métodos y clases estáticas o el patrón singleton.</li></li></ul><li>No realizar trabajo en el constructor<br />Mientras más trabajo hagamos en el constructor, más difícil será crear el objeto para hacer pruebas con el.<br />
  93. 93. No realizar trabajo en el constructor<br /><ul><li>Señales de que existe este problema:
  94. 94. El operador New en el constructor.
  95. 95. Cualquier tipo de llamada estática.
  96. 96. Cualquier tipo de lógica (condicionales, iteraciones).
  97. 97. Necesidad de llamar a un método «init» luego de la construcción del objeto.
  98. 98. Tener un constructor para pruebas y otros para producción.
  99. 99. Si el constructor realiza bastante trabajo, estaremos forzados a realizar todo ese trabajo en los tests.</li></li></ul><li>CompositionoverInheritance<br />Composition<br />Herencia<br />La herencia crea una fuerte relación entre la clase padre y las subclases; las subclases deben conocer muchos detalles de implementación de la clase padre. (Alta Dependencia)<br />
  100. 100. CompositionoverInheritance<br /><ul><li>El propósito de la herencia es el polimorfismo y no la reutilización.
  101. 101. Si no estamos sobrescribiendo, probablemente estemos abusando de la herencia.
  102. 102. Elegir la composición por defecto.</li></li></ul><li>Evitar Métodos Estáticos<br />Los métodos estáticos son código procedural y no Orientado a Objetos.<br />Al momento de ejecutar un test unitario, instancio la clase e intercambio sus dependencias reales con testdoubles. El problema con código procedural es que no hay nada que inyectar ya que no existen objetos y por lo tanto los tests no tienen control sobre estos.<br />
  103. 103. Integration TestingAutomate Testing<br />Email: snahider@gmail.com<br />Blog: http://snahider.blogspot.com<br />Twitter: @snahider<br />Angel Núñez Salazar<br />
  104. 104. Pruebas de Integración<br />Se encargan de realizar pruebas a dos o más módulos dependientes de software.<br />
  105. 105. ¿ Cuando es una prueba de Integración ?<br />Cuando involucra una o más clases en simultaneo.<br />Cuando el código se comunica fuera de las fronteras de su propio proceso.(base de datos, la red, el sistema de archivos)<br />
  106. 106. ¿ Porqué pruebas de integración?<br /><ul><li>En algún momento los componentes tendrán que comunicarse entre si y hablar con el mundo exterior.
  107. 107. Una buen conjunto de pruebas unitarias es aún más efectivo si es acompañado de otros tipos de test.
  108. 108. Cada tipo de test es una nueva capa de protección en nuestro sistema.
  109. 109. El balance y aplicación efectiva de todos los tipos de test es lo que te dará beneficios.</li></li></ul><li>Database Testing<br />¿Porqué?<br /><ul><li>Las BDs son parte complementaria de las aplicaciones y almacenan datos que son activos importantes.
  110. 110. Las BDs usualmente contienen lógica y realizan funcionalidad crítica para las organizaciones.</li></ul>Es esencial contar con un conjunto de pruebas automatizadas que validen la integridad y funcionamiento de la base de datos.<br />
  111. 111. Las BDs son un terreno complicado.<br />Malas herramientas.<br />Los cambios se conservan.<br />Actitud de los especialistas en BD.<br />Diferencia entre el modelo conceptual de la aplicación y el modelo de la bb.<br />
  112. 112. ¿ Qué probar ?<br />Aplicación<br />Inside<br /><ul><li>Tablas, Vistas
  113. 113. StoreProcedures, Triggers
  114. 114. Integridad Referencial, Cascadas
  115. 115. Defaults, Constraints, Sizes</li></ul>Base Datos<br />Outside<br />Inside<br /><ul><li>Conectividad
  116. 116. Registro de datos
  117. 117. Lectura de datos
  118. 118. ORM ( Metadata, Mappings)</li></ul>Outside<br />(Data Access Interface)<br />
  119. 119. Prerrequisito: Sandboxes<br />Un punto importante para tener pruebas repetibles y no erráticas es que cada prueba no se superponga.Esta tarea es más difícil si solo existe una única base de datos y todos ejecutando pruebas contra ella.<br />DevelopmentSandbox<br />DevelopmentSandbox<br />IntegrationSandbox<br />Demo/TestSandbox<br />ProductionSandbox<br />Proveer una base de datos diferente para cada actor o ambiente donde se vaya a ejecutar el conjunto de pruebas.<br />
  120. 120. ¿ Cómo probar ?<br />La ClaveComenzar cada prueba con la base de datos en un estado conocido.<br />Los Pasos<br />1.- Inicializar el estado de la base de datos.<br />2.- Ejecutar la prueba.<br />3.- Restablecer (limpiar) el estado para la siguiente prueba.<br />
  121. 121. Inicializar el estado de la BD<br />Pruebas Autosuficientes<br />Cada prueba manipula los datos de la BD en la forma que ella lo requiera.<br /><ul><li>Usualmente utilizado junto a un ORM.
  122. 122. Se puede combinar con patrones como: test data builder, objectmother.
  123. 123. Menor impacto en el tiempo de ejecución de las pruebas en comparación a las otras estrategias (cada pruebas inicializa solo lo que necesita)</li></li></ul><li>Inicializar el estado de la BD<br />Fuente de datos externa<br />Mantener archivos externos con datos que serán cargados cuando sea necesario (Archivos planos, XML).<br /><ul><li>Casi siempre con la ayuda de frameworks. Ejm: DBUnit.
  124. 124. Las frameworks permiten utilizar funcionalidad más avanzada.
  125. 125. Necesita una organización para los archivos (por tabla, por conjunto de pruebas, por prueba).
  126. 126. El mantenimiento de la pruebas es más difícil ya que también se tienen que mantener los archivos externos.
  127. 127. Mayor impacto en el tiempo de ejecución de la prueba.</li></li></ul><li>Restablecer el Estado <br />Nuke and Pave<br />Antes de cada prueba eliminar todo y volverlo a crear. (datos, tablas, datos + tablas)<br /><ul><li>Fácil de implementar.
  128. 128. Gran impacto en el tiempo de ejecución de la prueba. (poco escalable si existen muchas pruebas y datos)</li></li></ul><li>Restablecer el Estado <br />Transaction - Rollback<br />Realizar cada prueba dentro de una transacción y al finalizar su ejecución realizar un rollback para desechar los cambios.<br /><ul><li>Usualmente fácil de implementar.
  129. 129. Poco impacto en el tiempo de ejecución de las pruebas.
  130. 130. No se puede utilizar en todos los tipos de pruebas donde intervengan una base de datos.(pruebas que inician otros procesos)</li></li></ul><li>Usando una BD en Memoria<br />Podemos remplazar la base de datos real por una en memoria para los propósitos de las pruebas.<br /><ul><li>La principal razón es que son muy rápidas, tanto en la inicialización de estado, ejecución de la prueba y restauración del estado.
  131. 131. Esto es posible si la capa de acceso a datos da la seguridad de funcionar de la misma manera independientemente de la base e datos que se utilice.</li></li></ul><li>EjercicioRealizar pruebas de BD utilizando"Fuente de Datos Externa""Nuke and Pave"<br />Implementar los enfoques "Fuentes de datos Externa" y "Nuke and Pave" dentro de un conjunto de pruebas utilizando DbUnit.<br />Crear una prueba que verifique una búsqueda por filtros.<br />Crear una prueba que verifique la creación y eliminación de un objeto.<br />
  132. 132. EjercicioRealizar pruebas de BD utilizando"Pruebas Autosuficientes""Transaction - Rollback"<br />Implementar los enfoques "Pruebas Autosuficientes" y "TransactionRollback" .<br />Analizar que factores adicionales se deben considerar cuando se utiliza un ORM.<br />
  133. 133. Notas<br />

×