Doesn't a lot of refactoring involve change in responsibility between classes? At least I find that a lot in my code. In those cases, the interface of those classes might change (as the responsibility shifts elsewhere), which will of course cause test changes.
My understanding is that refactoring may require changes to unit tests, but not integration tests. On the other hand, there have been long, unfruitful Internet discussions about the precise definition of refactoring, and I find it's better to just find an agreement among your immediate peers. :-)
There are some who treat the phrase "public interface" as meaning the parts of a class which use the `public` keyword.
There are other people who treat the phrase "public interface" as meaning whichever way that users interact with the system, e.g. commandline arguments, HTTP request parameters, exposed modules of a library, etc.
Sounds like you're using the first terminology and others are using the second.
Why are you testing how the responsibility is divided between classes?
Yes, some times you have to make an unclean cut into your code to test something. But this is not the default situation. That's why the article has that "mostly integration" part on its title.
I think his argument was that unit tests don't hold up to "real-world" refactorings, because most of the time you change the interface of your classes. Unit tests work nicely if you have one fixed interface and you just refactor some specific implementation of that.
