Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

A testing strategy for hexagonal applications

792 visualizaciones

Publicado el


Publicado en: Software
  • Inicia sesión para ver los comentarios

A testing strategy for hexagonal applications

  1. 1. A Testing Strategy for Hexagonal Applications Matthias Noback @matthiasnoback
  2. 2. A test is not a unit test if: ● It talks to the database ● It communicates across the network ● It touches the file system ● It can't run at the same time as any of your other unit tests ● You have to do special things to your environment (such as editing config files) to run it. Michael Feathers:
  3. 3. A unit test: ● It's deterministic ● It's fast ● It makes it easy to uncover the reason of failure
  4. 4. The relation with hexagonal architecture? Hexagonal architecture automatically allows you to test bigger parts of your application in "the unit test way".
  5. 5. Isolation is key Separating domain from infrastructure code == Automatic and guaranteed increase of testability
  6. 6. Hexagonal architecture benefit no 2 Explicitly designed use cases, which are recognizable as such
  7. 7. A port: An intention of communication
  8. 8. An adapter: The supporting technology for that communication
  9. 9. Ports ● Incoming: primary actors (users, other systems calling us) ● Outgoing: secondary actors (databases, other systems we call, etc.)
  10. 10. Combining these two qualities of hex. arch. ● We can test more of our code "the unit test way" ● We distinguish ports as our application's use cases ● Means...
  11. 11. We can test our use cases using fast tests that are close to the domain and follow the definition of a unit test
  12. 12. Examples of use cases and their interactions ● Create a new meetup group ● Schedule a meetup ● Accept registrations ● List upcoming and past meetups ● Show details about talks, organizers, etc.
  13. 13. Without infrastructure ● No framework ● No controller action ● No database ● No external services ● No filesystem ● No system clock ● No randomness
  14. 14. Application service Repository interface calls uses implements W ebcontroller Testdriver MySQL Stub calls implements
  15. 15. How do we know if it works in production? We have interfaces for every port...
  16. 16. How do we know if it works in production? Now we should prove that the port adapters implement these contracts correctly
  17. 17. Adapter tests are called "Integration tests"
  18. 18. Integration tests ● Test a repository against the actual database ● Test an HTTP integration against the real webservice ● Test an application service using a real web controller
  19. 19. Application service W ebcontroller MySQL calls Repository interface implements
  20. 20. What's missing? A way to be sure that the deployable unit works
  21. 21. System tests ● Everything configured as much as possible like the real thing ● Only a few tests ("smoke tests")
  22. 22. Building confidence ● Unit ● Acceptance ● Integration ● System
  23. 23. Advantages ● Ability to catch bugs where they are ● Ability to postpone infrastructure decisions ● Ability to show to domain experts what you have done and talk about missing scenarios/examples
  24. 24. Matthias Noback @matthiasnoback