【问题标题】:How to test a decorater usage in typescript?如何在打字稿中测试装饰器的使用?
【发布时间】:2019-03-16 01:51:01
【问题描述】:

假设有一个属性装饰器,并且一个类在其某些属性上使用该装饰器。

function foo(options?: any) {
    return function (target: any, prop: string) {
        // some magic
    }
}

class Bar {
    @foo({ opt1: true }) zoo = 123
}

假设我已经在我的单元测试中涵盖了foo 的逻辑,现在我愿意编写一个测试来确保

Bar 类在其属性 zoo 上使用了 foo 装饰器,并带有选项 { opt1: true }

这个测试应该怎么写?

附: 我正在使用 jestts-jest 并在必要时向任何其他测试框架开放。

【问题讨论】:

标签: typescript unit-testing decorator


【解决方案1】:

这是一个有趣的问题。

装饰器是直接使用的,因此不能通过正常方式进行模拟。 这可能是使用jest bypass mock 的合法案例。

但是,IMO,您的测试目标错位了。 你不应该测试它被{ opt1: true } 调用的事实,如果可能的话,你应该测试使用这种装饰器的行为

测试它是否被 { opt1: true } 调用与您想要测试您的 findLCD(a: number, b: number) 以确保它已调用 Math.abs(a) 相同。

您应该关注行为(findLCD(a, b) 为您提供正确的结果),而不是代码的执行方式。

意思是,如果您的装饰器 @foo 做了一些可衡量的事情,请改为对其进行测试。

例如,如果@foo写了一些日志条目,想办法测试日志条目是否被写入,而不是@foo已经以某种方式被调用。

【讨论】:

  • 谢谢!我也在想我应该测试行为而不是实现。但这样做是不可取的。我的装饰器是一些验证器(必需、minLength 等),它们装饰某些成员变量并会影响一些计算变量以指示所有字段是否满足其约束。测试这种行为非常乏味。试想一下,有 10 个班级将@required 应用于其成员。这将导致 10xN 几乎相同的测试,这些测试实际上是在测试 @required 的行为,并且已经单独测试过。
  • 我仍然会说这就是您应该测试的对象。您始终可以重构您的代码以进行准确测试,同时将测试代码压缩为单行代码。
猜你喜欢
  • 2019-07-29
  • 2015-06-28
  • 2018-02-12
  • 2020-12-24
  • 2018-06-21
  • 2016-05-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多