I was just thinking about some code I was writing, and thinking about how a lot of functionality works better as a unit. For example, an object method whose logic is mostly self-contained (verifying internal state, etc.), v.s. a method that relies on state set in other parts of the object.
My own development has gravitated towards making object methods much more self-contained (i.e. correct no matter what the internal state), whereas years ago, I would have preferred relying on making sure that all methods always left things in a sane state. Now I do both. This increases code complexity somewhat, but I think the code I write now is vastly more reliable even if 'adjusted' by other developers.
That got me onto another train of thought. Unit tests tend to make code much more reliable, but what if there's an additional indirect benefit derived from the adjustment of code style?
If developers were to write code that was unit-test friendly, it tends to mean that each little piece of code is written to work as a separate unit. This just isn't required when testing larger pieces of a project.
Not only that, but it would force developers into writing the same general style of code...
I think a whole project whose development cycle was based around (or heavily used) unit testing would likely benefit in more ways than were intended by unit testing alone.