I have always found integration tests most important in order to test business logic when your customers pay for your trust and especially when they rely on your code for revenue while interacting with a third party. However, they should be thrown away immediately after proving your coded logic matches business requirements as they are slow and lose value and become tech debt quickly. Unit tests, if needed, should be even more temporary in my opinion. Often a CLI can be sufficient as a "unit test" during the development process.
>However, they should be thrown away immediately after proving your coded logic matches business requirements as they are slow and lose value and become tech debt quickly.
Can you expand on why integration tests should be thrown away once validated?
Isn't the idea that when you make a change later, these tests will ensure you haven't introduced a regression?
Integration tests can be very resource intensive. In larger projects the time it takes to run and set these up these is often daunting. Yes, the idea is regression of business logic in practice, but in reality I have found it leads to test resentment (and writers of those tests) and smaller or no test being written instead. Additionally the regressions added are often to the test suite itself and not the actual application.
