Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20180313 Keep Calm And Test Your Code RiojaDotNet

103 views

Published on

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

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

20180313 Keep Calm And Test Your Code RiojaDotNet

  1. 1. {R} KEEP CALM AND TEST YOUR CODE Alberto Ortiz Capellán @albertortizcape Software Developer
  2. 2. Ventajas de usar testing
  3. 3. Rapidez Detectar errores lo más rápido posible
  4. 4. CalidadGarantizar la calidad de nuestro código
  5. 5. FuncionalidadMantener todo funcionando
  6. 6. Reducir el tiempo de las pruebas manuales Tiempo manual
  7. 7. El testing manual es repetitivo, tedioso y consume demasiado tiempo Las tareas repetitivas son aburridas Lo aburrido conduce a fallos
  8. 8. Pasemos al testeo
  9. 9. 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
  10. 10. Isolated • Solo debe existir un motivo por el que falla un test • Evitar comprobaciones en la carga de datos • Deben ejecutarse sin un orden
  11. 11. Repeteable • Obtener los mismos resultados en las mismas condiciones • Un test no debe depender de las condiciones del entorno • Debe cargar sus propios datos
  12. 12. Self-Verifying • No es necesaria una inspección manual
  13. 13. Thorough and Timely • Deben escribirse a la vez que se escribe el código • Antes que el código si es TDD
  14. 14. Pirámide de test
  15. 15. Test unitarios • Definición • Dobles y ejemplos • Estructura de un test • Consideraciones
  16. 16. Prueba que garantiza la funcionalidad de una “unidad” de código
  17. 17. Definición • La definición de “unidad” es ambigua – Programación Funcional: Una sola función – Programación Orientado a Objetos: Una clase entera
  18. 18. Dobles • Objetos que remplazan objetos reales • Devuelven resultados programados – Beneficio: Agiliza los test – Contra: Simulan datos reales
  19. 19. Dobles • Termino basado en los especialistas de cine • Tipos – Fake – Dummy – Mocks – Stubs
  20. 20. Doble Fake • Objetos implementados • Solo los valores necesarios solicitados
  21. 21. Ejemplo doble Fake
  22. 22. Ejemplo doble Fake
  23. 23. Objeto doble Dummy • Objetos que no se usan directamente • Pueden tener valor null • Necesarios para: – Invocar una función – Construir un objeto
  24. 24. Ejemplo doble Dummy
  25. 25. Objeto doble Stubs • Objetos implementados de otros objetos • Necesarios para: – Simular llamadas y devolver valores fijo
  26. 26. Ejemplo doble Stubs
  27. 27. Ejemplo doble Stubs
  28. 28. 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
  29. 29. Ejemplo doble Mock
  30. 30. Estructura • Estructura de un test – Inicialización de los valores iniciales – Llamada al método a testear – Comprobación de los resultados esperados
  31. 31. Estructura • Reglas nemotécnicas para recordar la estructura de un test – Arrange, Act, Assert (AAA) – Given, When, Then
  32. 32. Consideraciones • Una clase de test por cada clase del proyecto • Testear las clases publicas • Cuidado con los cambios del código de “producción”
  33. 33. Test Integración • Definición • Tipos • Estructura • Consideraciones
  34. 34. Unidades independientes de software que funcionan correctamente cuando están conectadas entre ellas
  35. 35. Definición • Unidades independientes con vida propia – Bases de datos – Servicios – Sistemas de archivos – Librerías externas – ….
  36. 36. Tipos • Testean partes de la aplicación con vida propia – Test de integración con Base de datos – Test de integración con Servicios
  37. 37. • Caso idóneo A – Preparar un entorno – Insertar datos necesarios para realizar el test – Realizar el test – Eliminar el entorno (Opcional) Estructura
  38. 38. • Caso idóneo B – Insertar datos necesarios para realizar el test – Realizar el test – Borrar los datos introducidos Estructura
  39. 39. Pasos • Iniciar una transacción • Insertar datos necesarios • Pasar los test • Cancelar la transacción
  40. 40. Ejemplo test integración
  41. 41. Ejemplo test integración
  42. 42. Ejemplo test integración
  43. 43. Ejemplo test integración
  44. 44. Consideraciones • Uso de transacciones • Omitir test que dependan de datos existentes • Repetibles • Consistentes
  45. 45. Servicios • Mockear la respuesta del servicio • Pasar los test
  46. 46. Test de consumo de servicio
  47. 47. Test de consumo de servicio
  48. 48. Consideraciones • Mockear la respuesta del servicio • Servicio externo: Evitar consultar directamente – Denegación de servicio – Consultas limitadas – Afectar al rendimiento
  49. 49. Test interfaz de usuario • Definición • Consideraciones
  50. 50. Pruebas automatizadas sobre la interfaz de usuario de tu aplicación
  51. 51. Definición • Interfaz de usuario – Consola – Web – Escritorio – Servicio
  52. 52. Consideraciones • Beneficios: – Son las más próximas al usuario final – Reducen tiempo de pruebas manuales
  53. 53. Consideraciones • Contras: – Son MUY frágiles – Son lentas – Gran coste en detectar el error en código
  54. 54. 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
  55. 55. Test exploratorios
  56. 56. Test exploratorios • La automatización no es perfecta • Permiten conocer la aplicación • Encontrar errores complejos
  57. 57. Test exploratorios • Sensaciones al navegar por la interfaz – Diseños – Tiempos de respuesta – Falta de mensajes de error
  58. 58. Test exploratorios • Definir un objetivo • Limitar el tiempo de exploración • Recomendable documentar • Debe ser posible reproducir los errores
  59. 59. Consejos
  60. 60. 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, …)
  61. 61. Consejos • Porcentaje de pruebas por nivel – Test unitarios: 70% – Test integración: 20% – Test de interfaz de usuario: 10%
  62. 62. Consejos • Usar Integración Continua para detectar los errores

×