我有一个名为FooJob（）的类，它在WCF Windows服务上运行。这个类只有2个公共方法，构造函数和Run（）方法。
当客户端调用我的服务时，调暗Job类的新实例，将一些参数传递给ctor，然后调用Run（）......
Run（）将获取参数，执行一些逻辑，向外部数据供应商发送（实时）请求，获取响应，执行一些业务逻辑，然后将其放入数据库...
仅在Run（）函数上编写单个单元测试（如果可能的话）是明智的吗？或者我最终会在这里自杀？在这种情况下，我应该钻进私有函数和单元测试FooJob（）类的那些？但是，这会不会“打破”某些人在TDD中争论的“唯一测试行为”/公共接口范式？
我意识到这可能是一个模糊的问题，但任何建议/指导或正确方向的观点都会受到高度赞赏。
德鲁
答案 0 :(得分：2)
我的建议是让您的测试帮助您设计代码。如果你正在努力执行语句或函数，那么你的课程做得太多了。遵循单一责任原则，添加一些界面（允许你模拟复杂的东西），甚至可以阅读福勒的“重构”或羽毛的“使用遗留代码”，这些教会了我更多关于TDD的知识，而不是迄今为止的任何其他书籍。
答案 1 :(得分：2)
做一些逻辑，向外部数据供应商发送（实时）请求，接受响应，做一些业务逻辑，然后将其放入数据库
这里的问题是，您已经将您的班级列为具有多重职责......要真正进行单元测试，您需要遵循单一责任原则。您需要将这些职责分配到单独的界面中。然后，您可以单独测试这些接口的实现（作为单位）。如果你发现你不能轻易地测试你的班级正在做的事情，那么另一个班级可能应该这样做。
您似乎至少需要以下内容：
然后，您可以测试该业务逻辑，与外部供应商通信的过程以及单独保存到数据库的过程。然后，您可以模拟这些接口来测试Run（）方法，只需确保按预期调用方法。
为了正确地做到这一点，应该将类的依赖关系（上面定义的接口）理想地传递给它的构造函数（即依赖注入），但这是另一个故事。
答案 2 :(得分：1)
简单的答案是 - 这取决于。我编写了很多测试私有方法行为的单元测试;我已经这样做了，所以我很高兴我已经涵盖了针对这些方法的各种输入和方案。
现在，很多人认为测试私有方法是一个坏主意，因为重要的是公共方法。我明白这个想法，但就我而言，这些私有调用的公共方法也只是一个简单的Run（）方法。私有方法的逻辑包括从配置文件读取和在文件系统上执行任务，所有这些都是“幕后”。
如果我刚刚创建了一个名为Run（）的单元测试，那么我会觉得我的测试不完整。我使用MSTest为我的类创建访问器，以便我可以调用私有方法并创建各种场景（例如当我用完磁盘空间时会发生什么等）。
我猜这是他们自己用这个私有方法测试做/或不做参数。我的建议是，如果你认为你的测试不完整，换句话说，需要更多的覆盖，那么我建议测试私有方法。
答案 3 :(得分：1)
听起来你的跑步方法试图做太多我会把它分开但是如果你的整体设计不会允许的话。
我会考虑让内部成员受到保护，然后继承测试类中的类来测试它们。小心虽然我遇到了陷阱，因为它没有重置类状态所以Setup和TearDown方法是必不可少的。
答案 4 :(得分：0)
感谢大家的评论。我相信你是对的 - 我需要分成更多单独的课程。这是我使用真正的TDD进行的第一个项目之一，因为我根本没有进行任何类设计而只是编写存根代码......我必须承认，我喜欢编写这样的代码以及我可以证明这一点的事实。多年支持成功结果的管理纯粹是令人敬畏的真棒=）。
我唯一不确定的是过度工程和遭受阶级膨胀，当我可以只针对我的私人方法编写单元测试时...我想这里必须使用常识和程序员的直觉。 ..？