【发布时间】:2018-02-21 00:13:03
【问题描述】:
在执行单元测试时,最好测试我期望将其硬编码到测试中的文字结果 (expect(x).toBe(17)),还是测试逻辑而不是我正在使用的特定模拟数据更好 ( expect(x).toBe(mockedData.value))
第一种方法似乎更安全,因为我确信测试实际上是在测试我期望的文字结果,但是第二种方法更灵活,因为它允许我测试逻辑而不是担心模拟数据(我也可以稍后更改,而无需重写测试本身)
这两种方法的优点/缺点是什么?在这些情况下,最佳做法是什么?
下面是一个简单的例子:
// MockedData is a very long array of complex objects
// each of them has a property 'value' of type number
import mockedData from 'data.mock';
class ClassToTest {
private data;
constructor(data) {
this.data = data;
}
plusOne(): number {
return this.data.value + 1;
}
}
describe('test', () => {
let instance: ClassToTest;
beforeEach(() => {
instance = new ClassToTest(mockedData[0]);
})
it('plusOne() should return the property "value" plus one', () => {
// Should I write this...
expect(instance.plusOne()).toBe(mockedData[0] + 1);
// ...or this?
expect(instance.plusOne()).toBe(17); // Because I know that mockedData[0].value is 16
})
});
非常感谢!! :)
【问题讨论】:
-
这是一个很好的问题,不幸的是,它不适合 SO,因为没有正确的答案,无论哪种方式都有论据。在这种情况下,方法是 plusOne,看到断言是
something +1是有意义的。但是,在较少编造的情况下,使用硬编码数字通常更容易理解正在测试的内容(即使更改模拟数据时它会使测试更加脆弱。 -
TBH 你做了一个 input 17 = ouput 17 这不是测试。如果你这样做 input true = ouput 17 那么这是一个测试。尝试对组件进行测试,因为如果您提供正确的输入,您的服务应该始终给出预期的结果。如果不是,您的输入错误或您的后端流程错误。
-
IMO using
mockedData对这个测试用例更具描述性,如果是: 16.plusOne 应该返回 17 那么我同意使用文字。您的断言应与规范描述保持一致 -
您可以通过多种方式测试组件,所有方式都是针对特定条件设计的。它不像你只会使用一种方式而不是另一种方式。顺便说一句,您会将预期结果存储在硬编码文件中。这与技术无关。
-
顺便说一句,你的两个测试都失败了;)你需要调用方法
标签: javascript angular unit-testing jasmine karma-jasmine