我有一个名为FooJob（）的类，它在WCF Windows服务上运行。这个类只有2个公共方法，构造函数和一个Run（）方法。仅测试中型课堂上的公共方法？
当客户打电话给我服务，昏暗的作业类的新实例，传递一些参数的构造函数，然后调用运行（）...
的run（）将采取的参数，做一些逻辑，发送（实时）请求外部数据供应商，采取的应对，做一些业务逻辑，然后把它在数据库中...
是否明智只写一个单元测试，然后（如果甚至可能）在Run（）函数中？或者我会在这里结束自杀吗？在这种情况下，我应该钻入私有函数并单元测试FooJob（）类的函数吗？但是，那么这会不会“破坏”TDD中一些人认为的“唯一测试行为”/公共接口范例？
我意识到这可能是一个含糊不清的问题，但在正确的方向有什么建议/指导或点，将不胜感激。
Drew
做一些逻辑，发送（实时）请求外部数据供应商，采取的应对，做一些业务逻辑，然后把它在数据库
这里的问题是，你已经列出您的班级有多重责任......要真正进行单元测试，您需要遵守单一责任原则。您需要将这些职责分解到不同的界面中。然后，您可以单独测试这些接口的实现（作为单位）。如果你发现你不能轻易地测试你的课程正在做什么，那么另一个班级应该可以做到这一点。
好像你至少需要如下：
然后，您可以测试业务逻辑，与外部供应商进行通信的过程以及单独保存到数据库的过程。然后，您可以嘲笑这些接口来测试您的Run（）方法，只需确保按照您的预期调用这些方法即可。
为了做到这一点，理想的是将类的依赖关系（上面定义的接口）传递给它的构造函数（即依赖注入），但那是另一回事。
简单的答案是 - 它取决于。我写了很多单元测试来测试私有方法的行为;我已经这样做了，所以我可以很高兴我已经涵盖了针对这些方法的各种输入和场景。
现在，很多人都认为测试私有方法是一个坏主意，因为它是公共方法这一问题。我明白了这个想法，但就我而言，这些私人调用的公共方法也只是一个简单的Run（）方法。私有方法的逻辑包括读取配置文件并在文件系统上执行任务，所有这些都在“幕后”进行。
如果我刚刚创建一个单元测试，所谓的run（）的话，我会觉得我的测试是不完整的。我使用MSTest为我的类创建访问器，以便我可以调用私有方法并创建各种场景（例如，当磁盘空间不足时发生的情况等）。
我想这是每一个自己的这种私有方法的测试做/或不做的说法。我的建议是，如果你觉得你的测试不完整，换句话说，需要更多的覆盖，那么我建议测试私有方法。
我的建议是让你测试你的代码的设计帮助。如果你努力执行语句或函数，那么你的班级做得太多了。遵循单一责任原则，添加一些接口（允许你模拟出复杂的东西），甚至可以阅读福勒的“重构”或羽毛的“使用遗留代码”，这些教导我更多地了解TDD，而不是其他任何书籍。
这听起来像你的跑步方法试图做太多，我会分开它，但如果你是整体设计不会允许它。
我会考虑让内部成员受保护，然后从测试类中的类继承来测试它们。要小心，尽管我遇到过这样的问题，因为它不会重置类的状态，所以Setup和TearDown方法是必不可少的。
感谢大家的意见。我相信你是对的 - 我需要分出更多的单独课程。这是我使用真TDD的第一个项目之一，因为我根本没有上课设计，只是写存根代码......我得承认，我喜欢写这样的代码，事实上我可以证明我的理由与多年的备份成功结果mangagment是纯粹friggin真棒=）。
我唯一的缺点是过度工程和饱受类膨胀的困扰，当我可以对我的私有方法编写单元测试时......我想常识和程序员必须在这里使用...？
谢谢......但我有一个问题 - 我们在什么时候过度设计和构建太多的类，何时我们可以单元测试一些私有函数？这里有什么一般的经验法则吗？只要去你的肠道...？ – dferraro 2009-10-20 13:55:18
我建议看看面向对象设计的固体原则（http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod），其中单一责任原则是其中之一。我也尽量不考虑把事情分解成多个类来过度工程，因为每个类都变得更简单和更容易理解。我会说“如果你觉得需要单独测试一个私人方法，那么它应该是另一个班级”，这将是一个经验法则，以及我上面所说的必须列出课程责任的内容。 – ColinD 2009-10-20 15:59:48
我把课程分开，直到不能再分开为止。如果您避免返回值，并将类看作是将消息发送给另一个，则这变得更容易概念化。微类具有非常容易理解的好处，以及添加新行为通常是通过添加更多类来完成的，这意味着您可以单独保留现有的经过测试的代码。这是好事。 – kyoryu 2009-12-03 05:42:51