Test driven development. I get it, like it.But writing tests does require overhead. So should TDD be used universally throughout the code base, or are there areas where TDD provides a high ROI and other areas where the ROI is so low that it is not worth following.
Are there areas where TDD provides a high ROI and other areas where the ROI is so low that it is not worth following?
development process;tdd
I'd say avoid TDD in places where the code is likely to change structurally a lot.  Ie, it's great to have a pile of tests for a method whose signature changes rarely but gets refactored internally more frequently, but it sucks to have to fix your tests every time a highly volatile interface changes dramatically.The apps I've been working on recently have been data-driven webapps built on a Gui->Presenter->BusinessLogic->Data Access Layer-based architecture.  My data access layer is tested like nobody's business.  The business logic layer is pretty well tested.  The Presenters are only tested in the more stable areas, and the GUI, which is changing hourly, has almost no tests.