Descargar para leer sin conexión
![Comparativa
PHPUnit 4.1 Mockery 0.9 Phake 1.1 Prophecy 1.0 Notas
Invocation Count
Constraint
Ok Muy bueno Muy bueno Ok
Mockery/Phake son mejores.
Métodos atMost() y atLeast()
disponibles.
Ordered Expectations Ok Bueno Ok No
Mockery es mejor. Simplemente
usando ordered([group]).
Argument Matchers Bueno Ok Ok Ok
PHPUnit es mejor. Sobre todo con la
funcionalidad delta
Partial Mocking Ok Muy bueno Ok No
La construcción es mucho más
simple con Mockery.
Mocking Demeter
Chains And Fluent
Interfaces
Ok Muy bueno Ok Ok
Muy sencillo con Mockery y un poco
rebuscado con los otros.
Test Doubles Ok Bueno Ok Bueno
Prophecy es el único con spies y
Mockery el único que gestiona
static, final & private](https://image.slidesharecdn.com/desymfonyday2014-tomockornottomock-spanish-160306115632/85/To-mock-or-not-to-mock-34-320.jpg?cb=1675826438)
Subido porEloi Poch
To mock or not to mock
El documento presenta la metodología de pruebas de software de Akamon, abordando la importancia y tipos de tests: unitarios, de integración y de aceptación. Se discute la utilización de test doubles para optimizar el proceso de prueba y se comparan diferentes enfoques de testing. Finalmente, se ofrecen conclusiones y consejos para mejorar la efectividad de las pruebas, destacando la necesidad de evitar el acoplamiento excesivo en las pruebas unitarias.
To mock or not to mock
- 3. ¿Quiénes somos? Eloi PochJordi Llonch
- 4. Agenda • ¿Qué hacemosen Akamon? • To test or not to test? • ¿Cómo hacemos test? • Librerías de mock. • Conclusiones y consejos.
- 5. • Osiris: • Nuevaplataforma de servicios de Akamon. • Principios: • Simplicidad sobre facilidad. ¿Qué hacemos? Calidad Funcionalidad Velocidad
- 6. Domain Contract Infrastructure Domain (Business Logic) Contract Infrastructure Domain (Business Logic) Applications Background Website APIsAPIsAPIs Arquitectura byAkamon APIs DBs Contract External Services Infrastructure Domain (Business Logic)
- 7. Calidad • Pull Request •Test • Pair Programming by Akamon
- 8. To test ornot to test? Todo el m undo hace tests
- 9. To test ornot to test Los buenos test ahorran DINERO en cualquier aplicación
- 10. To test ornot to test
- 11. Testear es controvertido •David Heinemeier (creador de Ruby on Rails y Fundador y CTO de Basecamp) • TDD is dead. Long live testing & RailsConf 2014 Keynote - Writing Software by DHH • Hangouts entre Kent Beck, DHH y M. Fowler El caso DHH
- 12.
- 13. Un feedback rápido… …parael código que estamos escribiendo… …de una funcionalidad. ¿Qué queremos de los tests?
- 14. Testean de manerarápida una funcionalidad. ¿Qué hacen nuestros tests?
- 15. Infrastructure External Services Test Double TestDouble APIs DBs Contract Domain (Business Logic)
- 16. Test doubles • Implementaciónalternativa de un colaborador (clase o servicio) • Objetivo: • Hacer nuestros tests rápidos. • Aislar sistemas externos. • Testear casos extremos.
- 17. Test doubles • Tipos: •Dummy: Implementación no funcional. • Fake: Implementación completamente funcional pero no usable en un entorno real. • Stub: Implementación parcialmente funcional preparada únicamente para poder ser usada en el test. • Spy: Stub con memoria. • Mock: Spy con expectaciones sobre las llamadas a recibir que las auto-comprueba él mismo.
- 18. Tests Unitarios Pros Contras Rápidos Nopueden probar la ausencia de errores Permiten testear todos los casos Los doubles no son confiables Ayudan a encontrar problemas pronto Los doubles están acoplados a sus implementaciones Facilitan el cambio Buena documentación
- 19. Escuelas de TestsUnitarios Chicago / Classical London / Mockist Énfasis Algoritmo Envío de mensajes Enfoque Resultado, estado y efectos colaterales Roles, responsabilidades e interacciones Libro Test-Driven Development by Example Growing Object Oriented Software Guided by Tests
- 20. Unit Testing ::Chicago School • Pros: • Menor riesgo de expectaciones incorrectas. • Tests estables. • Menos mantenimiento. • Contras: • Ciclo largo de Red-Green-Refactor. • Explosión combinatoria de los casos a testear. • Un simple bug rompe muchos tests. • Más debugging para encontrar la raíz del error.
- 21. Unit Testing ::London School • Pros: • Facilita el enfoque. • Baby steps. • Contras: • Alto riesgo de expectaciones incorrectas (el refactoring no detecta cambios en los colaboradores) • Acople del test a la implementación. • Test frágiles.
- 22. Glosario • Test Unitarios: •Test del código y la lógica de negocio de una funcionalidad (operaciones con el contrato del módulo). • Test double: La infraestructura y los servicios externos. • Riesgo: • Test demasiado profundo que no permita testear de manera simple todas las casuísticas by Akamon
- 23. …pero los testunitarios no son suficientes…
- 24. Queremos saber silas integraciones con los sistemas externos funcionan correctamente.
- 25.
- 26. Tests de Integración ProsContras Confiables Lentos Encontrar problemas/cambios con servicios de terceros Imposible de testear algunos casos extremos Buena documentación
- 27. • Test deintegración: • Test de las implementaciones de los contratos/ interfaces de la infraestructura y los servicios externos. • Test double: Nada. by Akamon Glosario
- 28. …pero con testunitario e integración todavía no es suficiente…
- 29.
- 30. Tests de Aceptación ProsContras Amigables y entendibles para usuarios no técnicos Lentos Gran confianza Complicado de testear algunos casos Buena documentación Imposible testear algunos casos extremos Complicado localizar errores Complicados de escribir (estado inicial)
- 31. Glosario • Test deaceptación: • Test de una funcionalidad (end-to-end black-box mode). • Test double: Nada. by Akamon
- 32. Nuestra pirámide detests Acceptance Integration Unit
- 33.
- 34. Comparativa PHPUnit 4.1 Mockery0.9 Phake 1.1 Prophecy 1.0 Notas Invocation Count Constraint Ok Muy bueno Muy bueno Ok Mockery/Phake son mejores. Métodos atMost() y atLeast() disponibles. Ordered Expectations Ok Bueno Ok No Mockery es mejor. Simplemente usando ordered([group]). Argument Matchers Bueno Ok Ok Ok PHPUnit es mejor. Sobre todo con la funcionalidad delta Partial Mocking Ok Muy bueno Ok No La construcción es mucho más simple con Mockery. Mocking Demeter Chains And Fluent Interfaces Ok Muy bueno Ok Ok Muy sencillo con Mockery y un poco rebuscado con los otros. Test Doubles Ok Bueno Ok Bueno Prophecy es el único con spies y Mockery el único que gestiona static, final & private
- 35. Otro punto devista
- 36. Property-Based Testing • Aproximacióntotalmente diferente. • No se escriben los tests, se generan. • QuickCheck: Canonical framework escrito en Haskell. • ¿Cómo funciona?: • Describe las entradas y salidas permitidas y las transiciones de estado. • Genera aleatoriamente un gran número de casos de test y busca fallos. • Devuelve el mínimo ejemplo de fallo. • Casos de uso: Comportamientos no determinísticos y sistemas concurrentes.
- 37. Conclusiones En el mundodel testing lo más importante es determinar la unidad o sistema a testear. Los tipos de tests, los doubles e incluso los frameworks dependen de la unidad o sistema a testear.
- 38. Consejos • Evita Minimizalos dobles: • Están acoplados a la implementación ➙ Limitan la refactorización pura. • No son confiables ➙ Pueden tener un comportamiento diferente al real. by Akamon
- 39. Consejos • Los testunitarios testean código no funcionalidad: • TDD por si solo no es suficiente. • BDD por si solo puede ser suficiente (si no te importa la lentitud). • TDD + BDD = WIN by Akamon
- 40. Consejos • Separa lalógica del test de los datos del test: • Usa el @dataProvider de PHPUnit (no para los doubles). • Usa el Scenario Outline de Behat. by Akamon
- 41. • La unidada testear: • Mockists are dead. Long live classicists. • Unit Tests: Isolation • Mock aren’t stubs: Dummy, Fake, Stub and Mock • TTDD (Tautological TDD): An anti-pattern • The depth of tests • Avoid Testing Implementation Details, Test Behaviours • The Failures of "Intro to TDD" • The London School of Test Driven Development Referencias
- 42. • Test doubles: •Tests doubles • Mocks, fakes, stubs and dummies • The little mocker Referencias
- 43. • Contract tests(a.k.a integration tests): • Integrated tests are scam (Collaboration & Contract tests) • Integration contract tests Referencias
- 44. • La pirámidede los tests: • Test Pyramid • Testing Pyramid: A case study • Inverting the testing pyramid • Testing ice-crean corn anti-pattern Referencias
- 45. Referencias • Property-Based testing: •Better than unit tests • Powerful testing with test.check • Testing the Hard Stuff and Staying Sane
- 46. • Entrevistas aveteranos del TDD: • Ron Jeffries (One of the founders of Extreme Programming & Agile Manifesto) • Steve Freeman (Co-author of Growing Object- Oriented Software Guided by Tests) • James Shore (Author of The Art of Agile Development) • J.B. Rainsberger (Author of JUnit Recipes : Practical Methods for Programmer Testing Referencias
- 47.
- 48.