我一直在使用TDD来推动我目前正在进行的项目,结果相当令人满意.我确实遇到了一个问题(描述 here;仍然没有解决方案或任何建议！),其中某些特定方法的某些方面可能无法进行测试(如
那么,如何应对呢？我们是否只是接受这样一个事实,即某些逻辑路径是不可测试的(因为我们正在使用的框架或当前可用的测试框架中的限制)？
有些设计不适用于可测试性,尤其是那些没有可测试性作为设计目标之一的设计.通常TDDed设计不属于这一类.为了回答您的原始问题,我发布了一个响应,其中涉及使用反射来插入请求的错误代码.但是,这可能并不适用于所有情况,也不是一般解决方案.
这里的权衡是编写测试的努力与在自动化测试下使用特定代码片段的好处.如果您认为成本效益比很大且失败的可能性微乎其微,您可以将其作为特殊的手动测试,对未来的开发人员进行评论并立即手动验证.我说要务实,如果你花了30-40分钟开发人员的大脑时间试图让它受到考验,也许你需要退后一步并重新考虑你的策略.看看Michael Feather的“有效地使用遗留代码”,就克服可测试性障碍的一些建议.