When it's appropriate is not always clear. Those drinking the Kool-Aid will probably say you should always use it. Probably the biggest sticking point for me i

When it's appropriate is not always clear. Those drinking the Kool-Aid will probably say you should always use it. Probably the biggest sticking point for me is not knowing how your program should be structured ahead of time. You'll have trial and error along with plenty of refactoring, as you grapple with how the solution best fits the infrastructure you are writing for. Adding the overhead of writing tests for code/apis that are likely to change sounds like wasted effort. The fragmentation between different testing frameworks also doesn't help, with each having their own learning curve. Maybe people should focus on coding a minimum viable product, then revisit it after they understand better how their product should work in the infrastructure they are using. They will then have a better understanding of the tests they should write. The tests would likely come in handy as their program matures, and errors/downtime to their users becomes a bigger issue than pushing a product out the door.