| Here's how I look at it.. when writing code, you need to run it to try it. Often people refresh the browser or re-run their CLI program until their feature is finished. But if you think about it, every "refresh to check if it works" is just a manual test. TDD is just making that manual test automated. 1. Write that test (that you'd anyway have to run manually) 2. Write code until test pass 3. Repeat 1 until done. Code that aren't designed with a test-first mentality is often really hard to test and require complicated tools or need to mock the whole world. For the examples you've mentioned: - I'd unit tests the db service layer (I.e. functions to
fetch from db, make sure schema is valid) - I'd unit tests the various API queries (I.e. filtering, pagination, auth) - At the controller level, I'd just unit test the business logic and data fetching part. - Then I'd add a few E2E tests for the UI and user interactivity. But if you think about it, any of these tests would have had to be run manually anyway. I.e. You'd probably have queried your API with various options and refreshed the page(s) a few time to make sure data was fetched correctly. |