为何给出的C#代码不适合单元测试？什么样的代码具备良好的单元测试可测性？

简单说就是代码的结构支持你独立、快速、稳定地验证单个最小逻辑单元（通常是单个方法或类）的正确性，不会被其他无关逻辑干扰。一般符合以下几个特征：

• 被测单元的所有输入都可以由测试用例完全控制，没有隐式的内部依赖
• 被测单元的输出和输入严格对应，结果可预测
• 逻辑边界清晰，不需要依赖外部服务、文件、数据库等资源就能运行
• 测试执行完成后不会残留副作用，不会影响其他测试用例的结果

问题主要集中在A类的设计上：

• M1是私有方法，单元测试代码默认无法直接调用，必须修改访问权限或者用反射才能测试，额外增加了测试成本，属于设计层面就没有预留测试入口
• A的默认构造方法硬编码了依赖B的实例，无法做依赖隔离：要测试M1的逻辑，你需要覆盖MyB.X、MyB.Y不同取值的边界场景，但默认构造直接写死了MyB是默认初始化的B实例（X=3、Y=7），虽然MyB有公共setter可以修改，但如果使用方走默认构造初始化A，A的逻辑就和B的默认构造逻辑强绑定了，后续只要B的默认构造逻辑调整，哪怕A的代码一行没改，A的测试用例也会失败，无法单独验证A本身的逻辑正确性
• 另外M2的逻辑直接返回new B(x)，相当于把B的带参构造逻辑和M2的行为强绑定，如果后续B的带参构造计算Y的规则变化，M2的测试也会连带失败，没法单独验证M2的行为是否符合预期

内容的提问来源于stack exchange，提问作者tofana