[gremlinsinc]

I do a lot of rest api's, and generally, I just manage to test endpoints and data/json structures adhere to design specs or DTO's or typescript types, etc. I'm usually dealing w/ laravel but there's packages to translate backend DTOs to typescript types, for frontend devs to mess w/.

As long as all the restful resources work properly and get an expected outcome, there's a good chance everything else should work fine too.

[fedeb95]

yes if you have tables -> DTOs -> REST services without much logic the need for TDD beyond endpoints (I don't think it can be called TDD at that point) is limited. If you have services with lots of logic though... it could be useful to test that logic, if it's critical to business. Or if you deal with a framework used by different projects with different requirements, and/or if your software relies a lot on external configuration. Then features can (and will) clash so having some tests that detects those at different layers (unit, service, e2e, etc.) is good. Why TDD? Because it builds a system designed to be covered by tests. It's way harder to introduce tests later in critical parts of the system. This is textbook and in my experience also true. Again, different needs make TDD and automated tests more or less useful.