[英]How to Write Unit Tests for Functions That Contain SAPUI5 Core API?
I'm new to qUnit with UI5. 我是UI5的qUnit新手。
I want to test one function formatter.js
我想测试一个函数formatter.js
formatDate: function(sTimeStamp) {
if (sTimeStamp) {
var iTimeStamp = Number(sTimeStamp.match(/\d/g).join("")),
oDateTimeFormat = DateFormat.getDateTimeInstance();
return oDateTimeFormat.format(new Date(iTimeStamp));
}
return sTimeStamp;
},
Unit test for it: 单元测试:
function formatDateTestCase(assert, sValue, fExpectedNumber) {
var fDate = formatter.formatDate(sValue);
assert.strictEqual(fDate, fExpectedNumber, "Format Date was correct");
}
QUnit.test("Should return valid date", function (assert) {
formatDateTestCase.call(this, assert, "/Date(1510026665790)/", "Nov 7, 2017, 11:51:05 AM");
});
Obviously, this test case will fail when I change language setting. 显然,当我更改语言设置时,此测试用例将失败。 How to improve it? 怎么改进呢?
I think the main problem here is that formatDate
is a function with side effects. 我认为这里的主要问题是formatDate
是一个带副作用的函数。 Should I improve this function itself? 我应该自己改进这个功能吗? By adding locale in formatDate
? 通过在formatDate
添加语言环境?
Or should I use DateFormat
in my test case? 或者我应该在我的测试用例中使用DateFormat
? Which will make my test meaningless. 这将使我的测试毫无意义。
I think you should mock the calls to DateFormat
here to be able to independently test your code. 我认为你应该在这里模拟对DateFormat
的调用,以便能够独立测试你的代码。
Unit Test Considerations 单元测试注意事项
Strictly speaking the point of a Unit Test is to test your - and only your - Unit. 严格来说,单元测试的目的是测试你的 - 而且只测试你的 - 单元。 You should not test any dependent API. 您不应该测试任何依赖API。 One could argue about that in general but I would definitely NOT recommend to test SAPUI5 API. 总的来说,人们可以争论这一点,但我绝对不建议测试SAPUI5 API。
One the other hand I would strongly recommend to test the if
statement and the Regex part with invalid params (eg undefined
) and invalid strings. 另一方面,我强烈建议使用无效参数(例如undefined
)和无效字符串测试if
语句和Regex部分。 This will ensure your formatter to always work and to return sth. 这将确保您的格式化程序始终工作并返回某事。 meaningful if it is an empty string. 如果是空字符串则有意义。
Sinon.JS: Mocks, Stubs and Spys Sinon.JS:Mocks,Stubs和Spys
You should stub DateFormat.getDateTimeInstance()
in your specific test so that the method returns a predictable value (eg think of I18N in DateFormat
that would give you different test results in different languages). 您应该在特定测试中存储DateFormat.getDateTimeInstance()
,以便该方法返回可预测的值(例如,在DateFormat
中考虑I18N,它将为您提供不同语言的不同测试结果)。
To do that SAPUI5 already ships with Sinon.JS (be aware of the version included: SAPUI5 1.44 -> Sinon.JS 1.14). 为此,SAPUI5已经附带Sinon.JS (请注意包含的版本:SAPUI5 1.44 - > Sinon.JS 1.14)。 Here is a basic example: 这是一个基本的例子:
sap.ui.define([
"my/module/formatter",
"sap/ui/core/format/DateFormat",
"sap/ui/thirdparty/sinon",
"sap/ui/thirdparty/sinon-qunit"
], function (formatter, DateFormat) {
QUnit.test("Should return valid date", function (assert) {
// stub the method
sinon.stub(DateFormat, "getDateTimeInstance");
// ensure a predictable outcome
DateFormat.getDateTimeInstance.returns({
format: function(oDate) {
return oDate.getTime();
}
});
var fDate = formatter.formatDate("/Date(1510026665790)/");
assert.strictEqual(fDate, "1510026665790", "Format Date was correct");
// Optional: test if the stubbed function was called
assert.ok(DateFormat.getDateTimeInstance.calledOnce);
// don't forget to restore the stub so that it does not interfere with other tests
DateFormat.getDateTimeInstance.restore();
});
});
By stubbing DateFormat.getDateTimeInstance
you stop testing core API and it's outcomes and you can focus on what matters most: YOUR code. 通过存根DateFormat.getDateTimeInstance
您可以停止测试核心API及其结果,您可以专注于最重要的事情:您的代码。
BR Chris BR克里斯
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.