¿Quiénes somos?
Eloi Poch Jordi Llonch
Agenda
• ¿Qué hacemos en Akamon?
• To test or not to test?
• ¿Cómo hacemos test?
• Librerías de mock.
• Conclusiones y con...
• Osiris:
• Nueva plataforma de servicios de Akamon.
• Principios:
• Simplicidad sobre facilidad.
¿Qué hacemos?
Calidad
Fu...
Domain
Contract
Infrastructure
Domain
(Business Logic)
Contract
Infrastructure
Domain
(Business Logic)
Applications
Backgr...
Calidad
• Pull Request
• Pair Programming
• Test
by Akamon
To test or not to test?
Todo
el m
undo
hace
tests
To test or not to test
Los buenos test ahorran DINERO
en cualquier aplicación
To test or not to test
Testear es controvertido
• David Heinemeier (creador de Ruby on Rails y
Fundador y CTO de Basecamp)
• TDD is dead. Long li...
¿Cómo hacemos test?
Akamon
Way
Un feedback rápido…
…para el código que estamos
escribiendo…
…de una funcionalidad.
¿Qué queremos de los
tests?
Testean de manera rápida
una funcionalidad.
¿Qué hacen nuestros tests?
Infrastructure
External Services
Test Double
Test Double
APIs
DBs
Contract
Domain
(Business Logic)
Test doubles
• Implementación alternativa de un colaborador
(clase o servicio)
• Objetivo:
• Hacer nuestros tests rápidos....
Test doubles
• Tipos:
• Dummy: Implementación no funcional.
• Fake: Implementación completamente funcional pero no
usable ...
Tests Unitarios
Pros Contras
Rápidos
No pueden probar la ausencia
de errores
Permiten testear todos los
casos
Los doubles ...
Escuelas de Tests Unitarios
Chicago / Classical London / Mockist
Énfasis Algoritmo Envío de mensajes
Enfoque
Resultado, es...
Unit Testing :: Chicago School
• Pros:
• Menor riesgo de expectaciones incorrectas.
• Tests estables.
• Menos mantenimient...
Unit Testing :: London School
• Pros:
• Facilita el enfoque.
• Baby steps.
• Contras:
• Alto riesgo de expectaciones incor...
Glosario
• Test Unitarios:!
• Test del código y la lógica de negocio de una
funcionalidad (operaciones con el contrato del...
…pero los test unitarios
no son suficientes…
Queremos saber si las
integraciones con los sistemas
externos funcionan correctamente.
Infrastructure
External Services
APIs
DBs
Contract
Domain
(Business Logic)
Tests de Integración
Pros Contras
Confiables Lentos
Encontrar problemas/cambios
con servicios de terceros
Imposible de test...
• Test de integración:!
• Test de las implementaciones de los contratos/
interfaces de la infraestructura y los servicios
...
…pero con test unitario e
integración todavía no es
suficiente…
Applications
APIs
Background
Website
APIsAPIs
?
Domain
Module
User
Module
Analytics
Module
Marketing
Module
Device
Module
...
Tests de Aceptación
Pros Contras
Amigables y entendibles para
usuarios no técnicos
Lentos
Gran confianza
Complicado de test...
Glosario
• Test de aceptación:!
• Test de una funcionalidad (end-to-end black-box
mode).
• Test double: Nada.
by Akamon
Nuestra pirámide de tests
Acceptance
Integration
Unit
Librerías mock
https://github.com/Akamon/to-mock-or-not-to-mock
PHPUnit_MockObject
/** @test */!
public function it_should_publish_a_message()!
{!
$body = 'my message';!
$message = new M...
Mockery
/** @test */!
public function it_should_publish_a_message()!
{!
$body = 'my message';!
$message = new Message($bod...
Phake
/** @test */!
public function it_should_publish_a_message()!
{!
$body = 'my message';!
$message = new Message($body)...
Prophecy/** @var Prophet */!
private $prophet;!
!
protected function setup()!
{!
$this->prophet = new Prophet();!
}!
!
pro...
Comparativa
PHPUnit 4.1 Mockery 0.9 Phake 1.1 Prophecy 1.0 Notas
Invocation Count
Constraint
Ok Muy bueno Muy bueno Ok
Moc...
Otro punto de vista
Property-Based Testing
• Aproximación totalmente diferente.
• No se escriben los tests, se generan.
• QuickCheck: Canonica...
Conclusiones
En el mundo del testing lo más importante es
determinar la unidad o sistema a testear.
Los tipos de tests, lo...
Consejos
• Evita Minimiza los dobles:
• Están acoplados a la implementación ➙ Limitan la
refactorización pura.
• No son co...
Consejos
• Los test unitarios testean código no funcionalidad:
• TDD por si solo no es suficiente.
• BDD por si solo puede ...
Consejos
• Separa la lógica del test de los datos del test:
• Usa el @dataProvider de PHPUnit (no para los
doubles).
• Usa...
• La unidad a testear:
• Mockists are dead. Long live classicists.
• Unit Tests: Isolation
• Mock aren’t stubs: Dummy, Fak...
• Test doubles:
• Tests doubles
• Mocks, fakes, stubs and dummies
• The little mocker
Referencias
• Contract tests (a.k.a integration tests):
• Integrated tests are scam (Collaboration &
Contract tests)
• Integration con...
• La pirámide de los tests:
• Test Pyramid
• Testing Pyramid: A case study
• Inverting the testing pyramid
• Testing ice-c...
Referencias
• Property-Based testing:
• Better than unit tests
• Powerful testing with test.check
• Testing the Hard Stuff...
• Entrevistas a veteranos del TDD:
• Ron Jeffries (One of the founders of Extreme
Programming & Agile Manifesto)
• Steve F...
¿Preguntas?
¡Gracias!
Imágenes
http://transmedialshakespeare.files.wordpress.com/2011/01/3459513455_d1288a14b9_o.jpeg
http://info.fonality.com/Po...
DeSymfonyDay 2014 - To mock or not to mock - Spanish
DeSymfonyDay 2014 - To mock or not to mock - Spanish
Upcoming SlideShare
Loading in …5
×

DeSymfonyDay 2014 - To mock or not to mock - Spanish

890 views
685 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
890
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
4
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

DeSymfonyDay 2014 - To mock or not to mock - Spanish

  1. 1. ¿Quiénes somos? Eloi Poch Jordi Llonch
  2. 2. Agenda • ¿Qué hacemos en Akamon? • To test or not to test? • ¿Cómo hacemos test? • Librerías de mock. • Conclusiones y consejos.
  3. 3. • Osiris: • Nueva plataforma de servicios de Akamon. • Principios: • Simplicidad sobre facilidad. ¿Qué hacemos? Calidad Funcionalidad Velocidad
  4. 4. Domain Contract Infrastructure Domain (Business Logic) Contract Infrastructure Domain (Business Logic) Applications Background Website APIsAPIsAPIs Arquitectura by Akamon APIs DBs Contract External Services Infrastructure Domain (Business Logic)
  5. 5. Calidad • Pull Request • Pair Programming • Test by Akamon
  6. 6. To test or not to test? Todo el m undo hace tests
  7. 7. To test or not to test Los buenos test ahorran DINERO en cualquier aplicación
  8. 8. To test or not to test
  9. 9. 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
  10. 10. ¿Cómo hacemos test? Akamon Way
  11. 11. Un feedback rápido… …para el código que estamos escribiendo… …de una funcionalidad. ¿Qué queremos de los tests?
  12. 12. Testean de manera rápida una funcionalidad. ¿Qué hacen nuestros tests?
  13. 13. Infrastructure External Services Test Double Test Double APIs DBs Contract Domain (Business Logic)
  14. 14. Test doubles • Implementación alternativa de un colaborador (clase o servicio) • Objetivo: • Hacer nuestros tests rápidos. • Aislar sistemas externos. • Testear casos extremos.
  15. 15. 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.
  16. 16. Tests Unitarios Pros Contras Rápidos No pueden 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
  17. 17. Escuelas de Tests Unitarios 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
  18. 18. 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.
  19. 19. 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.
  20. 20. 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
  21. 21. …pero los test unitarios no son suficientes…
  22. 22. Queremos saber si las integraciones con los sistemas externos funcionan correctamente.
  23. 23. Infrastructure External Services APIs DBs Contract Domain (Business Logic)
  24. 24. Tests de Integración Pros Contras Confiables Lentos Encontrar problemas/cambios con servicios de terceros Imposible de testear algunos casos extremos Buena documentación
  25. 25. • Test de integración:! • Test de las implementaciones de los contratos/ interfaces de la infraestructura y los servicios externos. • Test double: Nada. by Akamon Glosario
  26. 26. …pero con test unitario e integración todavía no es suficiente…
  27. 27. Applications APIs Background Website APIsAPIs ? Domain Module User Module Analytics Module Marketing Module Device Module Economy Module Game Module Game Event
  28. 28. Tests de Aceptación Pros Contras 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)
  29. 29. Glosario • Test de aceptación:! • Test de una funcionalidad (end-to-end black-box mode). • Test double: Nada. by Akamon
  30. 30. Nuestra pirámide de tests Acceptance Integration Unit
  31. 31. Librerías mock https://github.com/Akamon/to-mock-or-not-to-mock
  32. 32. PHPUnit_MockObject /** @test */! public function it_should_publish_a_message()! {! $body = 'my message';! $message = new Message($body);! $serializedMessage = ['body' => $body];! ! $serializer = $this->getMock(SerializerInterface::class, ['serialize']);! $serializer! ->expects($this->once())! ->method('serialize')! ->with($this->identicalTo($message))! ->will($this->returnValue($serializedMessage));! ! $sender = $this->getMock(SenderInterface::class, ['send']);! $sender! ->expects($this->once())! ->method('send')! ->with($this->equalTo($serializedMessage))! ->will($this->returnValue(true));! ! $publisher = new Publisher($serializer, $sender);! $this->assertTrue($publisher->send($message));! }
  33. 33. Mockery /** @test */! public function it_should_publish_a_message()! {! $body = 'my message';! $message = new Message($body);! $serializedMessage = ['body' => $body];! ! $serializer = Mockery::mock(SerializerInterface::class);! $serializer! ->shouldReceive('serialize')! ->with(Mockery::mustBe($message))! ->once()! ->andReturn($serializedMessage);! ! $sender = Mockery::mock(SenderInterface::class);! $sender! ->shouldReceive('send')! ->with($serializedMessage)! ->once()! ->andReturn(true);! ! $publisher = new Publisher($serializer, $sender);! $this->assertTrue($publisher->send($message));! }
  34. 34. Phake /** @test */! public function it_should_publish_a_message()! {! $body = 'my message';! $message = new Message($body);! $serializedMessage = ['body' => $body];! ! $serializer = Phake::mock(SerializerInterface::class);! Phake::when($serializer)! ->serialize($message)! ->thenReturn($serializedMessage);! ! $sender = Phake::mock(SenderInterface::class);! Phake::when($sender)! ->send($serializedMessage)! ->thenReturn(true);! ! $publisher = new Publisher($serializer, $sender);! $this->assertTrue($publisher->send($message));! ! Phake::verify($serializer, Phake::times(1))->serialize($message);! Phake::verify($sender, Phake::times(1))->send($serializedMessage);! }
  35. 35. Prophecy/** @var Prophet */! private $prophet;! ! protected function setup()! {! $this->prophet = new Prophet();! }! ! protected function tearDown()! {! $this->prophet->checkPredictions();! }! ! /** @test */! public function it_should_publish_a_message()! {! $body = 'my message';! $message = new Message($body);! $serializedMessage = ['body' => $body];! ! $serializer = $this->prophet->prophesize(SerializerInterface::class);! $serializer! ->serialize($message)! ->shouldBeCalled()! ->willReturn($serializedMessage);! ! $sender = $this->prophet->prophesize(SenderInterface::class);! $sender! ->send($serializedMessage)! ->shouldBeCalled()! ->willReturn(true);! ! $publisher = new Publisher($serializer->reveal(), $sender->reveal());! $this->assertTrue($publisher->send($message));! }
  36. 36. 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
  37. 37. Otro punto de vista
  38. 38. Property-Based Testing • Aproximación totalmente 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 aleatóriamente 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.
  39. 39. Conclusiones En el mundo del 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.
  40. 40. Consejos • Evita Minimiza los 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
  41. 41. Consejos • Los test unitarios 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
  42. 42. Consejos • Separa la ló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
  43. 43. • La unidad a 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
  44. 44. • Test doubles: • Tests doubles • Mocks, fakes, stubs and dummies • The little mocker Referencias
  45. 45. • Contract tests (a.k.a integration tests): • Integrated tests are scam (Collaboration & Contract tests) • Integration contract tests Referencias
  46. 46. • La pirámide de los tests: • Test Pyramid • Testing Pyramid: A case study • Inverting the testing pyramid • Testing ice-crean corn anti-pattern Referencias
  47. 47. Referencias • Property-Based testing: • Better than unit tests • Powerful testing with test.check • Testing the Hard Stuff and Staying Sane
  48. 48. • Entrevistas a veteranos 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
  49. 49. ¿Preguntas? ¡Gracias!
  50. 50. Imágenes http://transmedialshakespeare.files.wordpress.com/2011/01/3459513455_d1288a14b9_o.jpeg http://info.fonality.com/Portals/65551/images/Presentation.jpg http://www.renders-graphiques.fr/image/upload/normal/organisateur_bloc_notes_agenda-.png http://www.luxfacta.com/wp-content/uploads/2014/01/programar.jpg http://www.kinderlandshop.es/WebRoot/StoreES2/Shops/eb0950/5020/E112/E380/66B2/C9CA/AC10/1414/0340/C05_1.jpg http://www.allpurposeabrasives.com.au/uploads/images/Quality%20Assurrance.jpg http://news.liv.ac.uk/wp-content/uploads/2013/03/knowledgeHOMEb.jpg http://www.worldnpa.org/site/wp-content/uploads/2013/01/hand-writing.jpg http://ievasapple.com/photo/images/my%20point%20of%20view.JPG http://www.snegmortgageteam.ca/wp-content/uploads/2013/12/mortgage-glossary.jpg http://birddogrealestate.net/wp-content/uploads/2012/09/Home-Toolbox.jpg http://www.balticblues-events.com/sites/default/files/images/ideas/photos/32-Live-Cooking1.jpg http://www.youwall.com/papel/on_my_way_wallpaper_fa2bb.jpg http://inheritancethefilm.com/wp-content/uploads/2013/06/thankyou.jpg http://www.ngn.com.au/wp-content/uploads/2013/07/Websites-on-white.png http://hn-marketing.co.uk/wp-content/uploads/2012/09/shutterstock_12553684.jpg http://picturesofmoney.org/wp-content/uploads/2013/04/Animated-American-Money-Falling-Into-a-Pile.jpg http://st.gdefon.com/wallpapers_original/wallpapers/18716_palma_more_plyazh_pesok_oblaka_tropiki_2560x1600_(www.GdeFon.ru).jpg http://i.imgur.com/DbTGPys.gif http://media.tumblr.com/e96b538708be71104f21689d3a820b9c/tumblr_inline_n54iazp56x1raprkq.gif http://i.imgur.com/8Lpsys5.gif

×