Most of my "unit tests" are functional by your criteria, at least as far as things like file I/O and database access are concerned. Maintain a reasonable separa

Most of my "unit tests" are functional by your criteria, at least as far as things like file I/O and database access are concerned. Maintain a reasonable separation between UI and the rest of your code, and this remains fairly straightforward even without any tool more fancy than xUnit and a collection of SQL scripts to automatically set up your test database. I've also found it easier in many cases to maintain a single parameterized test loop along with a library of sample data and corresponding "expected results" than lots of little tests in code. This is especially true in situations where you're changing code (and adding tests) directly in response to specific inputs your system failed to handle. And you can frequently re-use the same test loop on larger collections of sample data for other sorts of testing. More comprehensive testing including multiple servers, client user interfaces, and so on, tends to be labor intensive to set up and maintain even with good tool support, so here I suspect most of the answers boil down to time and money.