Presentación para la RiojaDotNet sobre testing. Enlaces de referencia: -- Keep Calm And Unit Test Your Code https://www.keepcalmandposters.com/poster/5829573_keep_calm_and_unit_test_your_code -- TestPyramid https://martinfowler.com/bliki/TestPyramid.html -- The Practical Test Pyramid https://martinfowler.com/articles/practical-test-pyramid.html -- TestDouble https://martinfowler.com/bliki/TestDouble.html -- UnitTest https://martinfowler.com/bliki/UnitTest.html -- IntegrationTest https://martinfowler.com/bliki/IntegrationTest.html -- Unit Tests Are FIRST (Fast, Isolated, Repeatable, Self-Verifying, and Timely) https://pragprog.com/magazines/2012-01/unit-tests-are-first -- F.I.R.S.T Principles of Unit Testing https://github.com/ghsukumar/SFDC_Best_Practices/wiki/F.I.R.S.T-Principles-of-Unit-Testing -- Simulando las dependencias en las pruebas unitarias. Dummies vs Stubs vs Mocks vs Spies vs Fakes http://www.javiergarzas.com/2015/09/dummies-vs-stubs-vs-mocks-vs-spies-vs-fakes.html -- What's the difference between faking, mocking, and stubbing? https://stackoverflow.com/questions/346372/whats-the-difference-between-faking-mocking-and-stubbing -- Mocks Aren't Stubs https://martinfowler.com/articles/mocksArentStubs.html -- Java - How to use stubs in JUnit https://stackoverflow.com/questions/31890991/java-how-to-use-stubs-in-junit -- GivenWhenThen https://martinfowler.com/bliki/GivenWhenThen.html -- Conceptos básicos de prueba unitaria - Escribir las pruebas https://msdn.microsoft.com/es-es/library/hh694602.aspx#Anchor_3 -- ¿Qué es eso del testing exploratorio? ¿Y para qué me sirve? http://www.javiergarzas.com/2015/01/testing-exploratorio-10-min.html -- Naming Test Classes and Methods https://codurance.com/2014/12/13/naming-test-classes-and-methods/ -- Rafa Gomez y Javier Ferrer - Clean Code, SOLID, CQRS... ¿Y qué hay de nuestros test? | BCN SWC 2017 https://www.youtube.com/watch?v=cw6Va1ZW7iI&list=PLKxa4AIfm4pXfHIuhB89H6TdUO8syJMui&index=3 -- Deconstruyendo la pirámide de los tests http://blog.koalite.com/2014/05/deconstruyendo-la-piramide-de-los-tests/ -- No pierdas el tiempo escribiendo tests http://blog.koalite.com/2017/11/no-pierdas-el-tiempo-escribiendo-tests/ -- NO automatices más Test de interfaz gráfica de usuario http://www.javiergarzas.com/2016/06/14044.html -- Just Say No to More End-to-End Tests https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html -- Commercial Fiat 500S – What bad boyS drive https://www.youtube.com/watch?v=4ndyAlJN9Fk

1. {R}
KEEP
CALM
AND
TEST YOUR
CODE
Alberto Ortiz Capellán
@albertortizcape
Software Developer

6. Ventajas de usar testing

7. Rapidez
Detectar errores lo más rápido posible

8. CalidadGarantizar la calidad de nuestro código

9. FuncionalidadMantener todo funcionando

10. Reducir el tiempo de las pruebas manuales
Tiempo manual

11. El testing manual es repetitivo, tedioso y
consume demasiado tiempo
Las tareas repetitivas son aburridas
Lo aburrido conduce a fallos

13. Pasemos al testeo

15. Fast
• Cuando más rápido > más ejecuciones
• No evitar su ejecución porque cuesta
mucho
• En milisegundos se deberían ejecutar
miles de test

16. Isolated
• Solo debe existir un motivo por el que falla
un test
• Evitar comprobaciones en la carga de
datos
• Deben ejecutarse sin un orden

17. Repeteable
• Obtener los mismos resultados en las
mismas condiciones
• Un test no debe depender de las
condiciones del entorno
• Debe cargar sus propios datos

18. Self-Verifying
• No es necesaria una inspección manual

19. Thorough and Timely
• Deben escribirse a la vez que se escribe
el código
• Antes que el código si es TDD

20. Pirámide de test

23. Test unitarios
• Definición
• Dobles y ejemplos
• Estructura de un test
• Consideraciones

24. Prueba que garantiza la
funcionalidad de una “unidad” de
código

25. Definición
• La definición de “unidad” es ambigua
– Programación Funcional: Una sola función
– Programación Orientado a Objetos: Una clase
entera

26. Dobles
• Objetos que remplazan objetos reales
• Devuelven resultados programados
– Beneficio: Agiliza los test
– Contra: Simulan datos reales

27. Dobles
• Termino basado en los especialistas de
cine
• Tipos
– Fake
– Dummy
– Mocks
– Stubs

28. Doble Fake
• Objetos implementados
• Solo los valores necesarios solicitados

29. Ejemplo doble Fake

30. Ejemplo doble Fake

31. Objeto doble Dummy
• Objetos que no se usan directamente
• Pueden tener valor null
• Necesarios para:
– Invocar una función
– Construir un objeto

32. Ejemplo doble Dummy

33. Objeto doble Stubs
• Objetos implementados de otros objetos
• Necesarios para:
– Simular llamadas y devolver valores fijo

34. Ejemplo doble Stubs

35. Ejemplo doble Stubs

36. Objeto doble Mock
• Ayuda de herramienta externa (C# Moq)
• Implementa solo aquellos métodos que
vamos a usar
• Necesarios para:
– Simular llamadas y devolver valores fijo

37. Ejemplo doble Mock

38. Estructura
• Estructura de un test
– Inicialización de los valores iniciales
– Llamada al método a testear
– Comprobación de los resultados esperados

39. Estructura
• Reglas nemotécnicas para recordar la
estructura de un test
– Arrange, Act, Assert (AAA)
– Given, When, Then

42. Consideraciones
• Una clase de test por cada clase del
proyecto
• Testear las clases publicas
• Cuidado con los cambios del código de
“producción”

45. Test Integración
• Definición
• Tipos
• Estructura
• Consideraciones

46. Unidades independientes de software
que funcionan correctamente cuando
están conectadas entre ellas

47. Definición
• Unidades independientes con vida propia
– Bases de datos
– Servicios
– Sistemas de archivos
– Librerías externas
– ….

49. Tipos
• Testean partes de la aplicación con vida
propia
– Test de integración con Base de datos
– Test de integración con Servicios

50. • Caso idóneo A
– Preparar un entorno
– Insertar datos necesarios para realizar el test
– Realizar el test
– Eliminar el entorno (Opcional)
Estructura

51. • Caso idóneo B
– Insertar datos necesarios para realizar el test
– Realizar el test
– Borrar los datos introducidos
Estructura

53. Pasos
• Iniciar una transacción
• Insertar datos necesarios
• Pasar los test
• Cancelar la transacción

54. Ejemplo test integración

55. Ejemplo test integración

56. Ejemplo test integración

57. Ejemplo test integración

58. Consideraciones
• Uso de transacciones
• Omitir test que dependan de datos
existentes
• Repetibles
• Consistentes

60. Servicios
• Mockear la respuesta del servicio
• Pasar los test

61. Test de consumo de servicio

62. Test de consumo de servicio

63. Consideraciones
• Mockear la respuesta del servicio
• Servicio externo: Evitar consultar
directamente
– Denegación de servicio
– Consultas limitadas
– Afectar al rendimiento

65. Test interfaz de usuario
• Definición
• Consideraciones

66. Pruebas automatizadas sobre la
interfaz de usuario de tu aplicación

67. Definición
• Interfaz de usuario
– Consola
– Web
– Escritorio
– Servicio

69. Consideraciones
• Beneficios:
– Son las más próximas al usuario final
– Reducen tiempo de pruebas manuales

70. Consideraciones
• Contras:
– Son MUY frágiles
– Son lentas
– Gran coste en detectar el error en código

71. Consideraciones
No intentar cubrir con test de interfaz todas
las casuísticas, solo las más importantes,
las que se usen más a menudo

72. Test exploratorios

73. Test exploratorios
• La automatización no es perfecta
• Permiten conocer la aplicación
• Encontrar errores complejos

74. Test exploratorios
• Sensaciones al navegar por la interfaz
– Diseños
– Tiempos de respuesta
– Falta de mensajes de error

75. Test exploratorios
• Definir un objetivo
• Limitar el tiempo de exploración
• Recomendable documentar
• Debe ser posible reproducir los errores

76. Consejos

77. Clean test code
• El código de testing es tan importante
como el de producción
• Solo UNA condición por test
• Mantener el código de los test bien
estructurado (AAA, Given When Then…)
• Aplicar reglas de clean code (DRY, KISS,
…)

78. Consejos
• Porcentaje de pruebas por nivel
– Test unitarios: 70%
– Test integración: 20%
– Test de interfaz de usuario: 10%

79. Consejos
• Usar Integración Continua para detectar
los errores