[eropple]

> There is almost no use for unit tests, as they lock down function implementations without verifying functionality.

This is...curious, given that every place I've ever been with any sort of testing culture tested contracts, not function implementations. They test the range and domain of the function, not the behavior of it.

Unit tests do not replace system-level/integration testing, but to dismiss them out of hand is manifestly unwise.

[ori_b]

Generally, I see a lot of testing of internal functions, which often should change their contract as refactoring happens.

All too rarely do I see people focusing testing on public APIs.

[eropple]

It depends on your definition of "internal". I write unit tests at whatever boundary that makes sense, and I certainly will write unit tests to test contracts between related pieces that others might call "internal." But then I can refactor trivially at that level, which I may (read: usually do) want to have available later.

I don't generally write, nor really see, see a lot of internal contractual testing in unit testing (not least because it becomes very hard to do so if you actually use visibility in OOP).