问题标签 [testability]

我有一些方法应该调用System.exit()某些输入。不幸的是，测试这些情况会导致 JUnit 终止！将方法调用放在新线程中似乎没有帮助，因为System.exit()终止了 JVM，而不仅仅是当前线程。是否有任何常见的模式来处理这个问题？例如，我可以用存根代替System.exit()吗？

[编辑] 有问题的类实际上是一个命令行工具，我试图在 JUnit 中进行测试。也许 JUnit 根本就不是适合这项工作的工具？欢迎提出补充回归测试工具的建议（最好是与 JUnit 和 EclEmma 很好集成的工具）。

“增强”组合框的所需功能是一种快速查找方法。组合框中的每个项目都有一个 ToString() 方法，以便它们可以显示在下拉列表中。单击下拉列表中的项目时，组合框的观察者会收到选择通知。

此外，每次组合框中输入的文本发生变化时，都会生成一个“候选人”列表，该列表由下拉列表中包含迄今为止输入的文本的所有项目组成。按 Enter 会将您带到该列表中的第一个候选人，反复按 Enter 循环您通过列表。

我已经通过从 ComboBox 派生来实现了这个功能——我认为这是有道理的，因为我仍然在功能上留下了一个组合框，它只是添加了这个“快速查找”功能。但是，创建候选列表并循环遍历它的逻辑虽然简单，但并非完全不重要，并且会进行一些测试。

然而，正如这里所看到的，仅仅通过构建它并刺激我添加的额外例程来测试 ComboBox 似乎并不那么容易 - 它需要存在于一个表单中，以便它的行为方式与它相同在应用程序中。测试一个简单的组合框的简单添加似乎太费力了！

但是，循环遍历候选对象的代码中没有任何内容特定于我的应用程序 - 我创建了一个可以在任意数量的上下文中使用的通用控件，唯一的要求是组合框中的对象具有 ToString() 方法，它无论如何，对进入普通组合框的对象施加的限制相同，并且由 C# .NET 保证。

那么，考虑到可测试性，您会将增强的功能放在哪里？

在设计我的对象时，我发现从可测试性的角度来看，组合是一个更好的选择。原因是，如果需要，我可以在运行单元测试时模拟部分组合结构。如果我有继承层次结构，这是不可能的。

我想知道其他人是否也发现这是更喜欢作曲的原因。另外，由于使用了继承，您还遇到了哪些其他可测试性陷阱？

有人负责创建一组“核心”库，创建了一组静态类，提供各种实用程序，包括日志记录、审计和常用数据库访问方法。

我个人认为这很糟糕，因为我们现在有一组难以测试的核心库，因为我无法模拟/存根这些类或对它们的构造函数进行任何注入。

我想我可以使用 TypeMock 将它们存根，但我宁愿免费做。

你怎么看？

编辑

如果您认为它们不难测试，您能否举例说明如何测试它们。这些静态类实例化其他类型来完成它们的功能。

全部，

想对此有一些想法。最近，在设计/开发时，我越来越成为“纯粹” DI/IOC 原则的订户。其中一部分（很大一部分）涉及确保我的类之间几乎没有耦合，并且它们的依赖关系通过构造函数解决（当然还有其他管理方法，但你明白了）。

我的基本前提是扩展方法违反了 DI/IOC 的原则。

我创建了以下扩展方法，用于确保插入到数据库表中的字符串被截断为正确的大小：

然后我可以从另一个类中调用我的字符串，如下所示：

不使用扩展方法的公平翻译是：

使用上述任一示例的任何类都不能独立于包含 TruncateToSize 方法（除了 TypeMock）的类进行测试。如果我没有使用扩展方法，并且我不想创建静态依赖项，它看起来更像：

在最后一个示例中，_stringUtil 依赖项将通过构造函数解析，并且可以在不依赖实际 TruncateToSize 方法的类的情况下测试该类（它可以很容易地模拟）。

从我的角度来看，前两个示例依赖于静态依赖（一个显式，一个隐藏），而第二个示例反转依赖并提供减少的耦合和更好的可测试性。

那么扩展方法的使用与DI/IOC原则有冲突吗？如果您是 IOC 方法的订阅者，您会避免使用扩展方法吗？

我们有一个类，它看起来像下面这样：

本质上，我们想编写一个单元测试来查看在指定时间后是否出现超时。显然，我们不希望每次运行测试都需要等待 10 分钟。考虑到这一点，我的问题是：

我们如何管理这个值，以便它在测试期间可能是 10 秒，但在生产中可能是 10 分钟？有很多明显的方法可以做到这一点，但我试图确定最干净的方法是什么。我们应该将其作为属性公开吗？将其作为构造函数参数包含在内？将其作为方法参数包含在内？使用编译器指令？

我有一个文件 - 在一个大型遗留代码库中 - 包含访问数据库的方法。没有使用任何类，只有一个带有方法声明的头文件，以及带有实现的源文件。

我想覆盖这些方法以消除单元测试期间的数据库访问。

我想到了以下选项：

1. 将文件放入类并覆盖方法。
   这里的主要缺点是它会导致整个代码库发生很多变化。
   不理想，虽然它确实改进了代码......
2. 用 an 包裹整个源文件#ifdef PRODUCTION_CODE并创建一个包含存根的新源文件并用相反的东西包裹它，即使整个东西编译依赖。这里的问题是，在执行回归测试的构建系统中，我必须编译两次，一次是为了创建应用程序并进行回归测试，另外一次是创建单元测试可执行文件。

有什么推荐的方法吗？

您是否应该设计代码以使测试更容易？如果是这样，如何设计c++代码以便于测试。

• 如何在 C++ 中应用依赖注入？
• 我是否应该使用纯接口类作为基础来实现这些类以简化伪造测试对象的创建？
  • 这将迫使我制作很多虚拟方法。这会影响性能吗？
• 在设计 C++ 中的可测试性时，我还应该考虑什么？

我有这段代码（你可能会忽略它是 Swing 代码），但我的构造函数中通常会出现太多参数。我应该使用模型 bean 类，然后在构造函数中传递该对象吗？

在这段代码中，我正在考虑添加更多由此类使用的对象。我是否继续添加更多参数并将它们传递给构造函数。可能使用设置注入？

但根据米斯科的说法，这也是代码异味。

http://misko.hevery.com/code-reviewers-guide/

“对象被传入但从未直接使用（仅用于访问其他对象）”

根据拥有可测试性博客的 Misko Hevery 的说法。开发人员应避免使用“持有人”、“上下文”和“厨房水槽”对象（这些对象包含各种其他对象并且是协作者的抓包）。传入您需要的特定对象作为参数，而不是该对象的持有者。

在示例中，这段代码有异味吗？我应该只传递需要的参数还是传递我需要的数据的模型/bean。

例如，你会做这样的事情吗：注意。我可能可以将数据作为构造函数参数传递。这是代码味道吗？

另一个问题：在编写可测试代码时，您是否倾向于编写太多类。有太多类或一个类有太多方法是错误的。这些类很有用并且只有一个目的。但是，我可以看到它们可以在哪里重构为一个更大的类……但是那个类有多种用途。