Stateful mock servers to the rescue on REST ecosystems
•
1 like•262 views
This document discusses the use of stateful mock servers to test REST APIs in microservices architectures. It describes some challenges with testing complex microservices ecosystems, including long test times due to dependencies. Stateful mock servers are proposed as a solution by replacing real dependencies with fake implementations that can be controlled during tests. Examples of different faking techniques like client fakes, proxies, and fake servers are provided. The document emphasizes generating mock server code to reduce development time and easily support contract and integration tests.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Stateful mock servers to the rescue on REST ecosystems
Similar to Stateful mock servers to the rescue on REST ecosystems (20)
More from Nuno Caneco
More from Nuno Caneco (8)
Recently uploaded
Recently uploaded (20)
Stateful mock servers to the rescue on REST ecosystems
- 1. Stateful mock servers to the rescue on REST ecosystems netponto - 2018-04-07 Nuno Caneco
- 2. Nuno Caneco /@nuno.caneco /nunocaneco nuno.caneco@gmail.com Engineering Manager / Cluster Lead @nunocaneco
- 5. The Monolith A monolith is a geological feature consisting of a single massive stone or rock, such as some mountains, or a single large piece of rock placed as, or within, a monument or building. https://en.wikipedia.org/wiki/Monolith A software system is called "monolithic" if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface) are all interwoven, rather than containing architecturally separate components. https://en.wikipedia.org/wiki/Monolithic_system
- 6. Monolithic architecture Storefront UI Backoffice UI Catalog Service User Service Order Service (...) Database Mobile Web API
- 8. REST REST has become the default technology to support Microservices Architecture ● It's HTTP(S) ● Use HTTP Verbs for actions: GET, PUT, POST, DELETE, PATCH, ... ● Use HTTP Status Codes to provide meaningful and normalized responses to clients ● Easily extensible using HTTP Headers ● Support multiple authentication mechanisms ● JSON is more simple and less verbose than XML
- 9. The growth of a Microservice Application
- 10. Ecosystem User interfacePublic API Backend Services Publish / Subscribe Databases BLOB Storage 3rd party systems
- 11. Component Dependency System Complexity ~= Business Complexity Loose coupling ; High dependency
- 12. Dependency level = 0 Dependency level = 10 Dependency level = 7 Teams & Components
- 13. Combine dependency level with ● Development environment ○ Setup ○ Maintain ● Keep services up to date ● Keep database schema and data ● Test ○ Time it takes to finish tests ○ Dependency from data ● CI/CD ○ Keep a stable environment for end-to-end tests ● Contract stability ● Communication between maintainers
- 15. Terminology Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example). Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent. Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive. https://martinfowler.com/articles/mocksArentStubs.html
- 16. Mock your dependencies Dependencies with real implementations are replaced by mocked implementations that provide similar behavior at the interface level.
- 17. Example
- 18. Example
- 19. Fake Techniques - Client Fake Client App XptoAPIClient Xpto Web API HTTP FakeXptoAPI Client IXptoApiClient Quick to implement and simple to use No new components on the system Using a Mock framework allows control of results on automated tests Doesn't test the HTTP layer Requires coding to implement statefulness The Production Code is not stimulated Potential risk to "Go Live" with the Fake instead of Real implementation
- 20. Fake Techniques - Proxy Client App XptoAPIClient Xpto Web API HTTP Quick to implement and simple to use Saved responses are similar to the real API No coding necessary (although possible) Easy to implement with containers Very flexible: easy to modify responses Contract changes invalidate previous saved responses Requires coding to implement statefulness Difficult to implement Expectations mechanism to integrated with automated tests Store and Forward Proxy HTTP Responses
- 21. Fake Techniques - Fake Server Client App XptoAPIClient Xpto Web API HTTP Not so flexible to change responses Requires coding Need to implement Expectations to integrate with automated tests Code generation accelerates development Easy support for contract changes: (just regenerate the code and change implementation) Easy to create and share containers Easy to implement statefulness Fake Xpto Web API Production&Integration Development&Tests HTTP
- 22. Demo I Proxy
- 23. Demo - Proxy Movie Rating UI MovieRating APIClient Movie Rating Web API HTTP Store and Forward Proxy Responses Omdb API
- 25. Demo - Fake Server Movie Rating UI MovieRating APIClient Movie Rating Web API Fake Xpto Web API Omdb API
- 26. Wrapping up
- 27. Integrating with docker Using docker to launch every 1st dependency allows easy setup of the project. $> git clone <repo> $> docker-compose up deps Open solution in Visual Studio and hit F5 No expensive setup of databases, messaging systems or other services Docker images can be versioned alongside with the versions of the API Can be used to run component tests (not integration tests)
- 28. Summary ● Fake the 1st level dependencies to avoid having the entire dependency tree ● Choose your strategy: Client Fake, Proxy, Stateful Fake or any other that suits ● Consider generating as much code as possible ● Potentially high upfront investment - big gains in the long run ● Make it easy for the developers to ○ Run the project ○ Manage the versions of the dependencies they are using ○ Write automated tests ● Make components tests running against Fakes instead
- 29. ANY QUESTIONS?
- 31. Patrocinadores “GOLD” Twitter: @PTMicrosoft http://www.microsoft.com/portugal
- 32. Patrocinadores “GOLD” Twitter: @FindmoreC http://www.findmore.pt/pt
- 35. http://bit.ly/netponto-aval-76 * Para quem não puder preencher durante a reunião, iremos enviar um email com o link à tarde
- 36. Próximas reuniões presenciais 07/04/2018 – Lisboa 23/06/2018 – Lisboa 15/09/2018 – Lisboa 24/11/2018 – Lisboa Reserva estes dias na agenda! :)