单元测试 – 测试“代理”;好的TDD还是代码味道？

当我为某些类型的对象编写测试时,比如Forms或UserControls之类的UI元素,我经常会发现自己正在改变我的TDD模式;而不是先测试,我定义并布置窗体的控件,提供“骨架”,然后开始编写行为测试(数据绑定/“解除绑定”,显示模式行为等).在这样做的过程中,我发现自己与非公共成员打交道.我也遇到了与其他行为方法相同的问题;在担心其他方法及其行为的使用之前,我可能想要关注并在另一个方法调用的私有帮助器中运行逻辑.

对我来说,让一切公开(有时是虚拟的)只是为了能够对所有东西进行单元测试就是一种气味;我不希望其他对象能够调用帮助程序,或直接访问文本框;但我需要知道帮助器完成它的工作,文本框在表单加载时获取其值.

我前段时间提到的解决方案是为测试中的实际对象创建一个“测试代理”.代理派生于被测对象,并不隐藏或覆盖任何行为,但它确实提供了内部可见的getter,setter和/或方法,可以调用被测对象的非公共成员,允许我告诉对象执行某些操作,然后我可以查看结果,而不要求测试依赖于对象内的正确集成,或者只是为了测试目的而在生产代码中公开该方法或其他一些感兴趣的成员.

我看到的优点：

>会员的可见度不取决于您是否需要进行单元测试.
>更好地控制在测试中可以对对象执行的操作,从而实现更灵活和可扩展的测试.

我看到的缺点：

>类计数增加,只为测试目的而开发一个额外的级别.
>必须注意不要以某种方式最终在生产代码中使用测试代理(使构造函数或整个类内部通常都有效)
>在某种程度上,不是“纯”单元测试,而是依赖于代理和被测对象之间的集成.

问题是,这是构建单元测试的有效方法,还是我必须这样做的事实表明代码或测试策略存在问题？