时间戳

首页 > 解决方案 > Scala 中编写和单元测试实用方法的良好实践

scala - Scala 中编写和单元测试实用方法的良好实践

问题描述

在特定情况下，您需要有一些跨不同类所需的实用方法。为了解决这种情况，您可以创建一个 Util 对象，在其中放置所有这些方法

object AggregatorUtil {
  def aggregateValues(list : List[BigDecimal]) = //some logic...
}

// Import everything in the Utilities object
import AggregatorUtil._

然后导入班级中需要的任何 util 成员。但是，这样做的缺点是，由于您的所有方法都在单例对象中，因此模拟使用实用方法的类的对象和单元测试方法变得很棘手。

为了再次解决这个问题，想到的唯一解决方案是将功能提取到特征中，然后模拟特征。

请让我知道是否有任何其他方法可以处理和测试 util 方法，以及哪种方法更简洁。

提前致谢 ！！！

注意：-我在我的项目中使用 scalatest 和 mockito。

标签： scalamockitoscalatest

解决方案

如果您需要模拟，将所有这些都放在模拟特征中是前进的方向。如果嘲笑是不必要的，请避免它。不必要的嘲笑是……不必要的。你只会在没有额外价值的东西上浪费时间和精力。

当您希望将其他文件中的复杂功能或功能视为黑盒并假设它按预期工作时，最好使用模拟（然后您通常会单独对这些东西进行单元测试）。如果您可以避免它并使用函数的实际功能，您将更真实地了解您的应用程序的功能，并更快地发现新的错误/重大更改（如果您已经模拟了功能并且忘记更新您的模拟，你可能没有发现任何你引入的新错误）。

当您在 MVC 应用程序（例如 Scala Play 微服务）中模拟对数据库的调用时，需要进行模拟的一个很好的例子是。您显然不想在测试代码时运行实际的数据库，因此您通常会模拟连接器层并从连接器函数返回虚拟/模拟数据。

你不会嘲笑的一个例子是：

trait MyTrait {
  def toInt(str: String): Int
}

val mockedTrait = mock[MyTrait]
when(mockedTrait.toInt(eq("3")).thenReturn(3)

这是一个有点愚蠢的例子，但我认为它清楚地解释了这一点——做这样的事情是荒谬的。嘲笑并不总是答案。

推荐阅读