问题标签 [testability]

我想实现 JUnit 测试以进行一些重构。首先，我想检查一下这个类有多好，是否为可测试性而实现。是否有任何指标和工具可以用来衡量 Java 类的可测试性？

假设我正在 Redux 中编写一个应用程序，并且我的任务是使用 3rd 方库添加日志记录。它的API如下：

然后我会使用这样的库：

我绝对想在应用程序初始化期间只创建一次记录器实例。但接下来的问题是：我在哪里存储记录器实例？

首先是把它放在商店的某个地方。但这是个好主意吗？正如我在代码中所展示的，记录器对象是有状态的，它在闭包中存储了一个计数器。我没有像使用不可变对象那样获得新实例。众所周知，状态只能通过纯 reducer 函数进行修改。

其他可能性是在 redux 中间件闭包的某个地方创建实例，或者只是创建一个全局变量，这在可测试性方面显然是邪恶的。

对于这种（我认为）相当常见的情况，是否有最佳实践？

我一直在开发一个命令行工具，它在某些输入上调用System.exit()（不想使用异常而不是）。

我熟悉Java：如何测试调用 System.exit() 的方法？它是最优雅的方法。

不幸的是，它不够纯净，因为我必须将依赖项添加到system-rules，junit-interface

System.exit在specs2中是否有任何常见的处理模式，它比我目前不使用specs2的方法更纯粹？

下面给出的是我的产品代码本质和简化表示。这就像一个完成工作流程的算法。每个步骤（私有方法）都会导致数据库中的记录发生更改。甚至外部工具调用也会导致通过另一种回调反馈机制更新数据库。

我的一位同事想为此编写一个集成测试用例，但不想包含外部工具调用。如果 BusinessWorkFlow 逻辑处于集成级别但不包括外部工具，他的目标是测试其余部分。不是使用模拟的单元测试，而是集成测试，他在其中验证数据库前后测试的状态。为了达到目的，他修改了这样的代码。

但是，我对这种重构风格不满意。由于外部工具的调用是业务工作流程中不可分割/不可分割的一部分，因此我宁愿不要将产品代码修改为具有指示工具调用是可选的布尔标志。

我认为更好的解决方案（但丑陋（？）因为它的性质）是坚持使用原始方法而不需要传入布尔标志依赖项。相反，决定调用该工具以支持嵌入在TriggerExternalToolTo_DoTask_B() 方法。或者甚至调用它 TryTriggerExternalToolTo_DoTask_B()。

就像是，

我也不赞成将 IWorkFlow.PerformBusinessWorkflowX(Input input) 方法分解为两部分（一部分执行前两个步骤，第二部分仅执行通过不同接口方法公开的工具调用），只是为了在产品代码方面具有灵活性并支持测试代码。也因为所有步骤都属于单个工作流程（算法）。

问题

1）我是否错误地说在产品代码中引入布尔标志只是为了支持测试可能不是最佳实践？（有些人告诉我，这就是可测试性设计。我希望这不是可测试性设计的真正含义）

2) 将调用逻辑推入 TryTriggerExternalToolTo_DoTask_B() 并依靠 appsetting 来救援的看似丑陋的解决方案是更好的解决方案吗？

3）看到我不想为了灵活性而分解方法（扩展接口），有没有更好的解决上述问题的方法？

PS - 如果我不了解，请纠正我并提供开放的技术建议。

由于我在 Java 中进行大部分编程，我发现在 Node.js 模块中导出类而不是对象实例是很有吸引力的，例如：

由于这样做需要跨依赖模块多次实例化该类，因此我仍然需要导出一个已经存在的实例以用于其余的生产代码。我在同一个模块中执行此操作：

这允许一些可测试性，因为可以在测试中交换真正的依赖关系：

这种方法有效，但它有一种奇怪的感觉，因为我在这里混合了两种模式：导出原型（用于单元测试）和实例（用于生产代码）。这可以接受吗？我应该继续这样做还是换成不同的东西？如果是这样，首选模式是什么？

我正在编写一个简单的控制台应用程序，我希望能够打印到屏幕上。

我可以在 Drive() 函数中使用 Console.Writline()，但我认为这不是一个好的设计，因为将来我可能希望将其记录到文件中。实现这种多输出日志记录功能的最佳设计是什么？控制台和文件输出（Iwritable）是否有一个通用接口，我可以将其传递给 Driver()，这样我就可以处理这两种类型的输出。还是有更好的设计来实现这一目标？

我有一个单元测试需要访问我的应用程序目标导入的模块上的内部方法/属性。

例如

子模块.swift

AppViewController.swift

AppViewControllerTests.swift

在此测试中，我在访问.value.

• 我已将SubModule目标添加到App-Tests“目标依赖项”
• 对于我正在编译以进行测试的方案，我已将 App 目标和 SubModule 目标的“启用可测试性”设置为 YES。

@testable import应该允许您在这些条件下访问标记为内部的类型。我不确定为什么会收到此编译器错误。我仍然可以使用在我的 App 目标中标记为内部的任何类型，@testable但不能使用我的 SubModule 目标。

您是否只允许 1 个目标出现@testable import在测试目标中，还是我遗漏了什么？

使用 Xcode 9、Swift 3.2

我的课程有几个领域。

以这种方式分配参数是因为我通过从 .csv 读取数据来创建此类的多个成员。我有另一个管理 Foo 实例列表的类。它通过从文件中读取它来立即创建整个列表并使用该列表进行计算。在类构造函数中创建列表时，它使用new Foo(string).

据我了解，这被认为是糟糕的设计，因为无法注入依赖项。此外，很难测试。如何在不使输入复杂化的情况下更改设计？这两个类的唯一目标是最终能够执行计算。

昨天，我在我的一个游乐场项目中实现了一个简单的类作为 IOC 容器（不太像那样），一些专业人士告诉我，在测试代码时会遇到一些问题（太紧张了，无法分享到底是什么）问题 ！！）

虽然我自己总是使用 IOC 框架，但我想知道为什么这种方法是不好的？

我什至使用这种方法编写了许多测试（使用模拟框架）并且从未遇到过问题。

我想要你关于这个设计问题的想法：

如您所见，我仅使 getChatPresenter 可访问，并且在我的视图中像下面这样使用它，并且效果很好。

代码在没有任何紧密耦合的情况下处理控制反转（使用接口）。

我想知道这种方法有什么问题吗？（我想从技术角度得到答案，因为我已经知道使用 Ioc 容器库更容易具有更多功能，例如范围等......）

实际上我想知道这种方法将来会带来什么问题和限制？

残忍地杀了我 :D

我正在使用 testng 和 Mockito2 为项目编写模块测试。我想模拟一些发出出站请求的方法。现在，要模拟的对象是在另一个对象的方法中本地创建的。所以，如果我说 4 个类，A、B、C 和 D，这样 A 创建 B 类型的对象，B 创建 C 类型的对象，依此类推，D 类型的对象要被模拟，我看到我有两个选择来模拟它。

选项 1 是监视 A、B、C 类型的对象，并将 B 的间谍注入 A 和 C 注入 B，最后在对象创建期间将 D 的模拟注入 C。下面是一个例子。

通过这种方式，我可以在调用 createB 时监视 A 并为 B 注入模拟对象。这样我最终可以模拟 D。

选项 2 是不模拟间歇性课程，而是直接拥有一个工厂类，如下所示：

上面的选项很简单，但我不确定这是否是正确的做法，因为它创建了更多静态方法，我相信应该避免这种情况。

我想知道应该首选哪种方法以及是否有其他替代方法。

请注意，我不希望使用 powermockito 或任何其他鼓励糟糕代码设计的框架。我想坚持使用mockito2。我可以重构我的代码以使其更具可测试性。