我的测试组中有两个测试。一个测试使用它,另一个使用测试。它们的工作原理似乎非常相似。它们之间的区别是什么?
describe('updateAll', () => {
it('no force', () => {
return updateAll(TableName, ["fileName"], {compandId: "test"})
.then(updatedItems => {
let undefinedCount = 0;
for (let item of updatedItems) {
undefinedCount += item === undefined ? 1 : 0;
}
// console.log("result", result);
expect(undefinedCount).toBe(updatedItems.length);
})
});
test('force update', () => {
return updateAll(TableName, ["fileName"], {compandId: "test"}, true)
.then(updatedItems => {
let undefinedCount = 0;
for (let item of updatedItems) {
undefinedCount += item === undefined ? 1 : 0;
}
// console.log("result", result);
expect(undefinedCount).toBe(0);
})
});
});
更新- 2022年11月:
根据Jest的官方API,测试和它似乎是可以互换的。正如这里所描述的@gwildu,出于可读性考虑,您应该选择其中一种。
正如其他答案所阐明的那样,它们做的是同样的事情。
我相信提供这两种方式是为了其中任何一种“RSpec”风格的测试,比如:
const myBeverage = {
delicious: true,
sour: false,
};
describe('my beverage', () => {
it('is delicious', () => {
expect(myBeverage.delicious).toBeTruthy();
});
it('is not sour', () => {
expect(myBeverage.sour).toBeFalsy();
});
});
或2)“xUnit”风格的测试,比如:
function sum(a, b) {
return a + b;
}
test('sum adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
文档:
https://jestjs.io/docs/en/api.html#describename-fn
https://jestjs.io/docs/en/api.html#testname-fn-timeout
正如其他答案所阐明的那样,它们做的是同样的事情。
我相信提供这两种方式是为了其中任何一种“RSpec”风格的测试,比如:
const myBeverage = {
delicious: true,
sour: false,
};
describe('my beverage', () => {
it('is delicious', () => {
expect(myBeverage.delicious).toBeTruthy();
});
it('is not sour', () => {
expect(myBeverage.sour).toBeFalsy();
});
});
或2)“xUnit”风格的测试,比如:
function sum(a, b) {
return a + b;
}
test('sum adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
文档:
https://jestjs.io/docs/en/api.html#describename-fn
https://jestjs.io/docs/en/api.html#testname-fn-timeout
它们做同样的事情,但它们的名字不同,因此它们与测试名称的交互作用也不同。
test
你写什么:
describe('yourModule', () => {
test('if it does this thing', () => {});
test('if it does the other thing', () => {});
});
如果某事失败了你会得到什么:
yourModule > if it does this thing
it
你写什么:
describe('yourModule', () => {
it('should do this thing', () => {});
it('should do the other thing', () => {});
});
如果某事失败了你会得到什么:
yourModule > should do this thing
所以这是关于可读性而不是功能性。
在我看来,阅读不是自己写的失败测试的结果是有意义的。它有助于更快地理解测试的内容。
一些开发人员还将Should do this thing缩短为Does this thing,这更短一些,而且在语义上也符合it符号。