[fedeb95]

Read about AMDD. The idea is: you not only write tests to design and iterate on that, but also sketch a model of your system and iterate that. Depending on the size you may want to sketch subsystems, etc.

Now the only problem I have with TDD is time. It takes a lot of time to do it right and usually I don't have that time (in my organisation). So maybe you can tdd some parts of your application, maybe the most critical parts. Even for personal projects you may not have the time: demotivation usually kicks in for personal projects. TDD defers results and the positive feedback needed to keep going. At least in my experience

[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.

[rcd2]

Thanks. I found an article about it and it looks like a interesting read.