How do you choose the right level and scope of testing for each feature or functionality?

Above description is absolutely wrong. Unit test = business rules, focus on the intents, no infra. Can/Should traverse as many classes as they want. Often starts at the hexagon entry point - aka Application Service / Use Case but you will find them too within some secondary adapters zone that denotes some logic. Integration test = Test secondary adapters exclusively, without any business rule involved. End-to-End test = Test primary adapters including components up to the bottom of the chain (infra). Should not exerce all business rules, only those that influence the primary adapter behaviours and system configuration. Some secondary ports might be substitutes (stubs/fakes) to avoid implicit dependencies often not deterministic.

In the context of React app development, here's how we decide what type of test to pick: - When the feature contains a Critical User Journey, we write an acceptance E2E/M test. It guarantees software behavior that is critical for our business to run, works. - When a feature contains a trivial user journey or edge cases, we employ integration tests to assert an outcome of a customer's interaction occurring on a single page: cy.mount( ‎ ‎ <TestProvider> ‎ ‎ ‎ ‎ <CreatePaymentPage /> ‎ ‎ </TestProvider> ); - For all the business logic within our React app, we use unit tests. These drive us to design logic separately from the rest of the app. Most of the times, the feature is developed using a combination of all these test types.

This is still a backbone of any app development. Despite of n number of strategies available in market for testing, we are still following this approach by starting with unit test, integration test and end to end testing. Yes, the way to narrate the cycle will be different based on stakeholder and application and budgets.

Please note that End-to-End (E2E) tests are also named acceptance or functional tests. They all mean the same - automation on the user level where subject under test (SUT) is an entire system. This, however, is not limited to just UI testing. For we development for instance sending HTTP request with various parameters and evaluating the response is a classic example of E2E test.

The testing pyramid we leverage to ship React apps with a zero-bugs policy: ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ / ‎\ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ /‎ M‎ \‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ — Manual & discovery testing ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎----- ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎/‎ ‎ ‎ ‎ ‎ E‎ ‎ ‎ ‎ ‎ \‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ — E2E/M tests ‎ ‎ ‎ ‎ ‎ ‎ ‎---------‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ 𝘤𝘳𝘪𝘵𝘪𝘤𝘢𝘭 𝘶𝘴𝘦𝘳 𝘫𝘰𝘶𝘳𝘯𝘦𝘺𝘴 ‎ ‎ ‎ ‎‎/‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ I‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎\‎ ‎ ‎ ‎ ‎ ‎ ‎ — Integration tests ‎ ‎ ‎ -------------‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ 𝘵𝘳𝘪𝘷𝘪𝘢𝘭 𝘶𝘴𝘦𝘳 𝘫𝘰𝘶𝘳𝘯𝘦𝘺𝘴 /‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ U‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎‎\‎ ‎ ‎ ‎ — Unit tests ‎-----------------‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎ 𝘣𝘶𝘴𝘪𝘯𝘦𝘴𝘴 𝘭𝘰𝘨𝘪𝘤

In the test-driven cycle, the right level and scope of testing for each feature or functionality are determined by a systematic approach. Initially, developers create unit tests to validate individual components, ensuring they meet specified requirements. Integration tests follow, verifying the interaction between these components. Finally, system tests assess the overall functionality of the feature. This iterative process enables continuous refinement of tests, aligning them closely with the desired behavior of the software. By adhering to this cycle, teams can effectively tailor the testing approach to the specific needs and complexities of each feature or functionality, ultimately enhancing product quality.

In ideal world test driven approach is also applicable on system level. When new requirement comes QA engineers start building acceptance (a.k.a. E2E, functional) test before or in parallel with development team doing real implementation. Once done test can be passed to developers to validate their implementation.

According to me, if we want to ensure the feature or functionality should be verified or tested thoroughly, we should take a mixed approach of development which includes TDD and BDD. Why should we take a mixed approach of development including TDD and BDD? Increased collaboration: As TDD deals with code which is owned by Engineers. And BDD is one where engineering and product can participate to cover all aspects of system or functionality behaviour. Increased Inclusiveness: This mix will foster the sense of shared ownership and the accountability across stakeholders like engineering and product. This mix will lead to a robust, well tested and user focused application.