In my personal experiance, highly testable code often equals good code. My deffinition of good code is that it should be loosly coupled layers, follow basic object oriented principals, small methods, good readability and it shouldn´t have much code duplication. I find, that if you think about testing or use TDD while writing your code, you will automaticly follow those "rules" pretty good. 

Testable code can be defined as code with small methods that have one and only one task and that uses interfaces to comunicate with other parts of the framework/application rather then implementations. Code like this is often easy for another developer to understand and work with and easy to test. If you use the TDD approach to development you will get testable code for "free", but even if you don´t, thinking about testing while writing your application usually result in a better structured application then if you don´t.

I think that all methods in a application should be written thinking that it should be testable and that someone will need to change this in the future. To me, the best way to find out what a method is supposed to do, is by looking at a unit test for it. Then you will see what it expects and what return values you can expect from it. It´s allways better to have many small methods then a few big once with alot of complexity.