你的代码可测试吗？

确实，只有好的设计，才能提高软件的可测试性。
我以为有利于测试的代码有这样几点特性：
1、状态少。
每个类的状态尽可能少。多个类组合之后的状态也尽可能少。如果一个类可以出现不必要的状态，那么这个类需要阻止这种状态的出现。
2、不信任。
调用方和被调用方互相不信任。调用方假设被调用方会返回错误的结果，而调用方假设被调用方会以错误的方法调用。
3、面向对象。
面向过程的程序难以测试，因为没有层次化的封装，可能会存在无数多个状态。如果要提高这类程序的质量，那么要尽可能在每个方法中不调用任何方法外部声明的变量，如果确实需要操作外部变量，把外部变量作为一个参数传递到方法中，这样此方法是可以单独测试的。（这个原则同样可以应用到一个类的内部）。
4、任何一个方法都尽量不改变内部成员的值。
5、尽量不使用无参数方法。（这样的方法一般都是改变状态的，参考原则3的说明）
以上都是一些经验之谈，不知大家有没有这方面的经验，可以拿出来参考一下？

很同意sloven_boy的看法，可测性的量度对设计者是否关注测试有着一定的关系。但是，并不是所有的设计在开始的时候就会关注测试，开始的时候我们有的只是需求，谈需求可测，对应的测试计划应该体现出测试的种种方案；业务的实现标准，到测试用例的时候我们关注的是业务用例的可测性，对应的业务对应测试用例，然而测试用例的关注点可能又会有所不同，等价类的划分很重要。
   最要命的这些东西大多是经验，根据环境的不同所总结出来的经验也不同，不同的时间、不同的项目工期，不同的项目组对可测性的标准不同。我们的代码真正是否可测，可能需要需求评审、设计评审时都让测试人员参与，但是真正关注文档可测性的测试人员又有几个呢？