I agree. Your unit tests should focus on testing individual pieces, the fundamental building blocks (classes and functions) that you have in your system. The changes should be isolated so when a class API changes only those unit tests would need to change.
I find the key thing here to be separation of concerns. Aim for testable classes and functions and that will make you also thing about the depencies.
For example I have class implementing NNT protocol. Initially one could think that this class needs to deal with IO or even worse with socket based data transfer. But if you think about it doesn't. The api can be based on an idea of getting a buffer full of data in and getting buffer Full of data out. Class coupled with IO/socket functionality = coupled hard to test without its trivial to unit test. (Reduced functionality class only maintains the protocol state doesn't concern itself where the data comes or goes)
I find the key thing here to be separation of concerns. Aim for testable classes and functions and that will make you also thing about the depencies.
For example I have class implementing NNT protocol. Initially one could think that this class needs to deal with IO or even worse with socket based data transfer. But if you think about it doesn't. The api can be based on an idea of getting a buffer full of data in and getting buffer Full of data out. Class coupled with IO/socket functionality = coupled hard to test without its trivial to unit test. (Reduced functionality class only maintains the protocol state doesn't concern itself where the data comes or goes)
Reference.
https://github.com/ensisoft/newsflash-plus/blob/master/engin...