在单元测试中使用什么货币?

时间:2015-03-12 02:16:19

标签: java unit-testing joda-money

我正在开发一个严重依赖Joda-Money的应用程序,并且有许多单元测试可以验证我的业务逻辑。对我来说,一个(不可否认的是次要的)关键点是要测试的Money / BigMoney个对象;具体来说,CurrencyUnit使用什么。

在我看来,我有几个选择:

  • 只需使用USD

    即可

    这显然是最简单的方法,而且我的大多数实际应用都将使用美元,因此它有一点意义。另一方面,它感觉相当以美国为中心,我担心它会冒险让货币特定的错误不受控制。

  • 使用其他真实货币,例如CAD

    这会抓住USD的错误硬编码,但除此之外没有比使用USD好多了。

  • 使用专用的"fake" currency,即XTS

    这显然是有道理的,毕竟XTS“保留用于测试”。但Joda将伪货币表示为小数位数-1的货币。实际上,Joda-Money中货币之间的主要区别是小数位数,因此这可能会掩盖任何涉及小数位精度的错误,例如错误地舍入为整数值。

  • 使用CurrencyUnit.registerCurrency()

    注册我自己的自定义货币

    这显然有效,但看起来有点奇怪,因为有其他选择。

  • 使用模拟库创建的CurrencyUnit实例

    与注册自定义货币几乎相同。

同样,这显然是一个小问题,但我很好奇是否有这样的案例的标准做法,或者是否有明确的理由特别喜欢其中一个选项。

2 个答案:

答案 0 :(得分:4)

使用USD(或者,通常,您的应用程序中最常用的货币)。我说这有两个原因:

  • 除了测试实际上涉及的部分之外,良好的测试数据在各个方面都不起眼。当您编写的测试与货币之间的差异没有任何关系时,您不必考虑货币之间的差异。只需使用应用程序中最自然的东西。

  • 在任何地方使用不寻常的货币会以某种方式导致更好地测试不寻常的货币的想法是一个红色的鲱鱼。测试应该是明确的,重点突出的。如果您需要测试某种特定货币的某些东西,请编写一个测试点,即测试该东西。如果测试不是针对特定货币,那么在处理该货币的某些不寻常方面时不应该破坏 - 因为同样的原因让一半的测试中断是没有价值的;你只想要打破一个人。因此,没有必要在测试套件周围传播不寻常的货币,并希望这会抓住一些东西。相反,优化可读性;见第1点。

答案 1 :(得分:0)

由于您的大多数应用程序都使用美元,因此将它们用于绝大多数测试是有意义的。您担心会发生哪些特定于货币的错误?复利时缺少半便士?转换为日元后的汇率下跌了1美分或2分?为此编写测试。

如果我是您,那么我将启动本地REPL(如果您没有JShell,Scala REPL会很好地工作),请运行一些实验。您可能会发现自己什么都不担心。否则,您可能会发现确实存在缺陷,您的REPL会话将告知您如何编写针对该缺陷的测试。

您使用Joda Money是因为您不想重新发明这个特殊的轮子。在阅读问题详细信息之前,我没有意识到这一点。大概Joda Money已通过其开发人员的严格测试,它可以完成您期望的所有操作。您无需再次测试。

但是,如果您要使用自己的班级来代表金额,我建议您使用美元,欧元,日元和利比亚第纳尔(LYD)。前三个原因很明显。由于小数点后三位,我建议使用Lybian第纳尔。据我所知,没有实际的1迪拉姆硬币,因此,例如513 darahim将被四舍五入为500 darahim,而997 darahim将被四舍五入为一个完整的第纳尔。

要测试转换,我先从东加勒比元(XCD)开始,因为它们固定为兑换$ 2.70美元。以后您可能会担心货币彼此之间会波动,以及是否要通过模拟费率服务器或通过连接到实际的费率服务器但在测试中采用差异或通过其他方式来处理货币