Recommended
More Related Content
Similar to Component Testing Slides.pptx
Similar to Component Testing Slides.pptx (20)
Recently uploaded
Recently uploaded (20)
Component Testing Slides.pptx
- 2. About Me Jordan Powell Developer Experience Engineer @JordanPowell88 jordanpowell88.com
- 3. The Agenda Why Cypress Component Testing Demo Q&A
- 5. Pages
- 6. Components
- 7. Cypress Component Testing Confluence Component Driven Development Acceleration & Adoption of CDD Frameworks Autonomous Teams Scalable & Decoupled Reuse & Consistency Improved Maintainability https://itnext.io/a-guide-to-component-driven-development-cdd-1516f65d8b55
- 8. Documentation Confidence Isolation Improved UX Why Component Testing?
- 10. Cypress Component Testing Confluence Test Driven Development Component Testing Enforces TDD
- 15. What Are The Differences Between E2E And Component Testing?” “
- 16. Identifying What To Test Confluence What is E2E testing? E2E Testing is a technique that tests your app from the web browser through to the back end of your application Cypress runs end-to-end tests the same way users interact with your app by using a real browser, visiting URLs, viewing content, clicking on links and buttons, etc. Testing this way helps ensure your tests and the user's experience are the same.
- 17. Confluence Benefits: - Ensure your app is functioning as a cohesive whole - Tests match the user experience - Can be written by developers or QA Teams - Can be used for integration testing as well Considerations: - More difficult to set up, run, and maintain - Provision testing infrastructure in CI - Testing certain scenarios require more setup Common Scenarios: - Validating critical workflows like authentication or purchasing - Ensuring data is persisted and displayed through multiple screens - Running Smoke Tests and System Checks before deployment End-to-End Testing
- 18. Identifying What To Test Confluence What is Component Testing? Modern web frameworks provide ways to write applications by breaking them into smaller logical units called components. Components can range from fairly small (like a button) to more complex (like a registration form). Component tests differ from end-to-end tests in that instead of visiting a URL to pull up an entire app, a component can be "mounted" and tested on its own. This allows you to focus on testing only the component's functionality and not worrying about other nuances with testing a component as part of the larger application.
- 19. Confluence Benefits: - Easier to test components in isolation - Fast and reliable - Easy to set up specific scenarios in tests - Don’t rely on any external system to run Considerations: - Do not ensure overall app quality - Do not call into external APIs/Services - Usually written by developers working on the component Common Scenarios: - Testing a date picker works properly for a variety of scenarios - That a form shows and hides specific sections based on input - Testing components coming out of a design system Component Testing
- 20. Confluence E2E Component What’s Tested All app layers Individual component Characteristics Comprehensive, slower, more susceptible to flake Specialized, quick, reliable Used For Verifying app works as a cohesive whole Testing functionality of individual component Written By Developers, QA Team, SDETs Developers, Designers CI Infrastructure Often requires complex setup None needed Initialization Command cy.visit(url) cy.mount(<MyComponent />) Testing Type Comparison
- 21. User Journeys 1 User Searches for a Product Adds to Shopping Cart 2 Enters Shipping Information 3 Enters Payment Information 4 Completes Order 5
- 22. User Journeys 1 User Searches for a Product Adds to Shopping Cart 2 Enters Shipping Information 3 Enters Payment Information 4 Completes Order 5
- 28. You Get The Point…
- 29. Getting Started
- 33. Demo
- 34. About Me Jordan Powell Developer Experience Engineer @JordanPowell88 jordanpowell.online
- 35. Questions?
Editor's Notes
- The reason why software development teams and QA teams are separate is because both teams view an application completely differently. Developers are responsible for building things, while QA professionals are responsible for breaking things. If developers want to write tests, they need to learn to think the way that a QA professional does and then translate that way of thinking into automated tests.
- Rule of 10’s
- Rule of 10’s
- The reason why software development teams and QA teams are separate is because both teams view an application completely differently. Developers are responsible for building things, while QA professionals are responsible for breaking things. If developers want to write tests, they need to learn to think the way that a QA professional does and then translate that way of thinking into automated tests.
- Rule of 10’s
- Rule of 10’s
- You should always begin by writing tests for your application's most "mission-critical" pieces. When I say "mission-critical," I mean any portions of your application that cannot go down or break. For example, login/authentication, purchasing a product, processing a credit card, sign-up forms, etc.
- You should always begin by writing tests for your application's most "mission-critical" pieces. When I say "mission-critical," I mean any portions of your application that cannot go down or break. For example, login/authentication, purchasing a product, processing a credit card, sign-up forms, etc.
- I recommend writing tests for "user journeys." User journeys are the essential paths in which a user of your application takes. For example, let's say you have an e-commerce application. Searches for Product Adds to Cart Enters Shipping Info Enters Payment Info Complets Order With one test, you are testing the most critical pieces of your application, which will ultimately provide you with confidence that your application is behaving as it should.
- I recommend writing tests for "user journeys." User journeys are the essential paths in which a user of your application takes. For example, let's say you have an e-commerce application. Searches for Product Adds to Cart Enters Shipping Info Enters Payment Info Complets Order With one test, you are testing the most critical pieces of your application, which will ultimately provide you with confidence that your application is behaving as it should.
- I recommend writing tests for "user journeys." User journeys are the essential paths in which a user of your application takes. For example, let's say you have an e-commerce application. Searches for Product Adds to Cart Enters Shipping Info Enters Payment Info Complets Order With one test, you are testing the most critical pieces of your application, which will ultimately provide you with confidence that your application is behaving as it should.
- I recommend writing tests for "user journeys." User journeys are the essential paths in which a user of your application takes. For example, let's say you have an e-commerce application. Searches for Product Adds to Cart Enters Shipping Info Enters Payment Info Complets Order With one test, you are testing the most critical pieces of your application, which will ultimately provide you with confidence that your application is behaving as it should.
- I recommend writing tests for "user journeys." User journeys are the essential paths in which a user of your application takes. For example, let's say you have an e-commerce application. Searches for Product Adds to Cart Enters Shipping Info Enters Payment Info Complets Order With one test, you are testing the most critical pieces of your application, which will ultimately provide you with confidence that your application is behaving as it should.
- I recommend writing tests for "user journeys." User journeys are the essential paths in which a user of your application takes. For example, let's say you have an e-commerce application. Searches for Product Adds to Cart Enters Shipping Info Enters Payment Info Complets Order With one test, you are testing the most critical pieces of your application, which will ultimately provide you with confidence that your application is behaving as it should.
- I recommend writing tests for "user journeys." User journeys are the essential paths in which a user of your application takes. For example, let's say you have an e-commerce application. Searches for Product Adds to Cart Enters Shipping Info Enters Payment Info Complets Order With one test, you are testing the most critical pieces of your application, which will ultimately provide you with confidence that your application is behaving as it should.
- Ultimately, testing is everyone's responsibility. In the real world, there are basically three team structures within modern software companies.
- The reason why software development teams and QA teams are separate is because both teams view an application completely differently. Developers are responsible for building things, while QA professionals are responsible for breaking things. If developers want to write tests, they need to learn to think the way that a QA professional does and then translate that way of thinking into automated tests.
- The reason why software development teams and QA teams are separate is because both teams view an application completely differently. Developers are responsible for building things, while QA professionals are responsible for breaking things. If developers want to write tests, they need to learn to think the way that a QA professional does and then translate that way of thinking into automated tests.
- Rule of 10’s