Testing Strategy in Micro Frontend architecture
•Download as PPTX, PDF•
0 likes•830 views
Testing Strategy in Micro Frontend architecture by Vishal Sharma and Brijendra Singh
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Testing Strategy in Micro Frontend architecture
Similar to Testing Strategy in Micro Frontend architecture (20)
More from vodQA
More from vodQA (20)
Recently uploaded
Recently uploaded (20)
Testing Strategy in Micro Frontend architecture
- 1. © 2022 Thoughtworks | Confidential Testing Strategy in Micro Frontend architecture - Vishal Sharma - Brijendra Singh
- 2. © 2022 Thoughtworks | Confidential 2 Monoliths Monolith Frontend Backend Monoliths aren’t a bad design choice
- 3. © 2022 Thoughtworks | Confidential 3 Microservices ● Strong module boundaries ● Independant deployments ● Diversified Technologies service 1 service 2 service 3
- 4. © 2022 Thoughtworks | Confidential 4 MicroServices + UI Monolith There was mostly a monolith UI, which made independent deployments less true. service 1 service 2 service 3 UI Monolith Independent deployments aren’t independent releases.
- 5. © 2022 Thoughtworks | Confidential 5 Micro-frontends Microservices’ promises + Independent releases. Micro frontends is an architectural design pattern to break down monolith UI to a smaller and manageable deployable units. service 1 service 2 service 3
- 6. © 2022 Thoughtworks Agenda Advantages of the micro-frontend architecture 07 Micro Frontend Example 08 Orchestrating Micro Frontends 09 Demo of the Micro Frontend App 10 Testing Strategy 12 Advantages of the architecture in terms of testing 14 Challenges of the architecture in terms of testing 24 Teams and Collaboration 21 6
- 7. © 2022 Thoughtworks | Confidential 7 ● Independent teams ● Independent releases ● Simple, decoupled codebases ● Incremental upgrades What you get from Micro-frontends 7
- 8. © 2022 Thoughtworks | Confidential 8 Image carousel Product Summary Pricing & Promotion Recommendations Product Information Customer Reviews Ratings Micro Frontend Example Product Detail Page
- 9. © 2022 Thoughtworks | Confidential 9 Orchestration Options Build Time Run Time Client Side Edge Side Server Side Orchestrating Micro- frontends
- 10. © 2022 Thoughtworks | Confidential Demo of a Micro Frontend App 10
- 11. © 2022 Thoughtworks | Confidential Key decisions Orchestrating Micro-frontends Testing Micro- frontends Slicing the Micro- frontends Micro-frontends communication Key Questions that need to be answered 11 ●How to identify and slice the micro- frontends. ●How should we test the micro- frontends? ●How do the micro-frontends communicate with each other. ●How do multiple micro-frontends come together to form a single application.
- 12. © 2022 Thoughtworks | Confidential 12 Testing Approach Manual session based testing Automated unit tests Automated component tests Automated integration tests Automated API test Automated GUI tests Pyramid Swiss Cheese - Korny’s Blog
- 13. © 2022 Thoughtworks | Confidential Advantages of the Architecture in terms of testing 14
- 14. © 2022 Thoughtworks | Confidential MFE component can be tested in isolation 15 Faster feedback
- 15. © 2022 Thoughtworks | Confidential MFE component can be tested in isolation 16 Ways of working Definition of Done x-platform Performance [UI/API] Security Accessibility Reporting Testing Metrics Tailor made Quality Strategy can be build for Individual MFE based on its use case
- 16. © 2022 Thoughtworks | Confidential Appropriate automation testing 17
- 17. © 2022 Thoughtworks | Confidential High quality e2es - less flaky UI tests 18 Appropriate automation testing
- 18. © 2022 Thoughtworks | Confidential Can be Independently Released 19
- 19. © 2022 Thoughtworks | Confidential Demo of Test Suit and CI/CD Pipeline 22
- 20. © 2022 Thoughtworks | Confidential Pipeline Overview of a Mobile Micro frontend
- 21. © 2022 Thoughtworks | Confidential App level automation test might get delayed 24 An application can have multiple e2e solution and repositories App level Integration/smoke e2e ownership will be required Team collaboration might be needed depending on the Integration pattern Challenges of the Architecture in terms of testing
- 22. © 2021 Thoughtworks | Confidential Teams and collaboration - Communication is the Key 25 © 2022 Thoughtworks | Confidential
- 23. © 2021 Thoughtworks | Confidential 26 Shared guidelines ● All teams should speak the same vocabulary ● Agree on terms of responsibility and ownership. Each team owns their own MFE but all the teams are responsible for the quality of the App. ● Maintaining proper documentation, testing guidelines and conventions which can be shared across teams. ● Try to maintain a global project scaffolding (but make it optional) © 2022 Thoughtworks | Confidential
- 24. © 2021 Thoughtworks | Confidential Team guilds Forum for like minded people from different teams to share and discuss 27 27 © 2021 Thoughtworks © 2022 Thoughtworks | Confidential Quality Guild
- 25. © 2022 Thoughtworks | Confidential Micro-frontends is a marathon. Not a sprint 28 28 © 2022 Thoughtworks Q&A
- 26. © 2021 Thoughtworks | Confidential Q&A 29 © 2022 Thoughtworks | Confidential
- 27. © 2022 Thoughtworks Thank You 30 © 2022 Thoughtworks Brijendra Singh Vishal Sharma
Editor's Notes
- Let us start by looking at the architecture has evolved in the past.
- Talk in terms of Miro services so that audience can relate.
- Let them explore the Amazon PDP page.
- Talk in very laymans terms Build time is like npm packages. Relate them to jar files. Run time is downloading the artifact on run time.
- Focus more on how testing can be performed on sliced micro-fontends and also how Integration of different Micro-Frontends can be tested
- The test pyramid -> A classic metaphor in automated testing is the test pyramid: it's been a useful model for ages, and still a good conversation starter, but it lacks a few things: It isn't clear really what the horizontal dimension is - does wider mean more tests? More test scenarios? More features tested? It isn't clear what the vertical dimension is - where do contract tests fit? What if you test at an API not a UI? Should you test in a particular order? In many cases the best shape is nothing like a pyramid - some systems are well suited to integration tests, and tend to a pear-shape. Some systems are more of an hourglass, with lots of UI/API tests and lots of unit tests and not much between. I've seen people tweak the pyramid - adding layers, adding axes, adding explanations. And in some point of time it can be confusing too. A different perspective - Swiss Cheese the Swiss Cheese model of testing . It's a lot more helpful when it comes to talking about both why we test, and how we should test. The basic idea is: consider your tests like a big stack of swiss cheese slices - you know, the kind with holes in them: Now layer those cheese slices vertically - each layer represents a different kind of tests. Order them in the order you run them - usually simplest, fastest feedback first, then slower layers below them: You can imagine defects as physical bugs which fall down the diagram, and are caught at different levels - different slices of cheese. Some bugs might fall all the way through a series of holes and not get caught. This is bad.
- I do think there's value in some browser-driven end-to-end tests - there are bugs we can only catch that way. But we can call them "smoke tests" or "end-to-end tests" or something, not "acceptance tests". If we want lots of tests of UI features, consider tools that test within the framework we use - we might want several "cheese slices" of UI tests - see how the material UI tests are layered for an example.
- Lets understand the testing strategy by going through the advantages of the architecture.
- Tailor made Quality Strategy can be build for Individual MFE based on their use case. Quality Strategy can include Ways of working Definition of Done Satisfy x-functional testing needs Performance [UI/API] Security Accessibility x-platform Bug bash Testing layers
- Brijendra
- Brijendra
- Brijendra
- With all the good things, comes its challenges also. An application can have multiple e2e solution and repositories : there might be some level of duplicate tests in app level automation suite, and that is perfectly ok considering the ways these tests are executed.