单元测试属性修饰符答案

【问题标题】：Unit testing property modifier单元测试属性修饰符
【发布时间】：2020-09-18 17:43:20
【问题描述】：

我说的是 Typescript，但它可能是一个通用问题...

如何测试一个属性是只读的？

我的意思是，它是一种语言特性，所以似乎很明显，如果我将一个属性声明为只读，没有人可以重新分配它，因为代码不会编译，但没有任何测试，没有人向我保证我可以安全地更改代码，使属性可写，然后修改它... 那么如果属性是可写的，我该如何编写一个失败的单元测试呢？

【问题讨论】：

您需要实现运行时检查才能做到这一点，因为 typescripts readonly 仅在编译期间。在运行时它确实是可写的。因此，如果不修改代码，您就无法对其进行单元测试。此外，您通常不想对此进行单元测试。而是测试你的类的外部接口的行为，并在测试过程中尽量不依赖内部状态。
“单元测试”并不是我们确保工作质量的唯一工具。

【解决方案1】：

你能写出这样的测试吗？是的;使用普通的 javascript 调用你的 Typescript 代码转换成的 javascript 代码。

但是，应该您编写这样的测试吗？没有。

使用诸如 Typescript 之类的转译和/或编译语言的主要原因之一是编译器承担了部分正确性负担。具体来说，就是语言提供的保证的正确性。

所以请坐下来享受编译器为您完成的繁重工作。

一个警告：如果您的项目混合使用 javascript 和 Typescript，那么您可能想要考虑它，但最好还是花时间将 javascript 位重写为 Typescript。

编辑：从测试的角度来看情况：如果测试现在通过而稍后由于回归而失败，需要什么？好吧，由于如果以后的某些编辑修改了readonly 属性，代码将无法编译，因此此编辑必须包括从属性中删除readonly。但是看到并拒绝了这个守卫，如何阻止编辑器删除现在也失败的测试？

所以在某种意义上，readonly 修饰符是测试。

【讨论】：

当然，这正是我的想法。由于它是一种语言功能，我可以离开编译器以确保没有人可以修改该属性。我担心删除只读属性的可能性。编译器可以避免更改属性，但不能避免删除关键字才能对其进行修改。而且我认为不变性是“要求的功能”。如何将其反映到代码中？通常所有功能都通过测试来确保，但是对于这种事情，哪种方法最好？
我理解您的担忧。我已经编辑了答案来解决这个问题。

【解决方案2】：

您是否还要测试其他属性是私有的还是公共的？不要走那条路。这显然是过度测试的案例。

【讨论】：