Automated Testing - Test-Driven JavaScript Development - page 15

detail of strftime , which would make that function the correct entry point to
test the behavior. However, because Date.formats.y is a publicly available
method, it should be considered a unit in its own right, which means that the afore-
mentioned test probably should have exercised it directly. To make this distinction
clearer, Listing 1.14 adds another format method, j , which calculates the day of the
year for a given date.
Listing 1.14 Calculating the day of the year
Date.formats = {
// ...
j: function (date) {
var jan1 = new Date(date.getFullYear(), 0, 1);
var diff = date.getTime() - jan1.getTime();
// 86400000 == 60 * 60 * 24 * 1000
return Math.ceil(diff / 86400000);
},
// ...
};
The Date.formats.j method is slightly more complicated than the previous
formatting methods. How should we test it? Writing a test that asserts on the
result of new Date().strftime("%j") would hardly constitute a unit test
for Date.formats.j . In fact, following the previous definition of integration
tests, this sure looks like one: we're testing both the strftime method as well as
the specific formatting. A better approach is to test the format specifiers directly,
and then test the replacing logic of strftime in isolation.
Listing 1.15 shows the tests targeting the methods they're intended to test
directly, avoiding the “accidental integration test.”
Listing 1.15 Testing format specifiers directly
testCase("strftime test", {
setUp: function () {
this.date = new Date(2009, 9, 2, 22, 14, 45);
},
"test format specifier %Y": function () {
assert("%Y should return full year",
Date.formats.Y(this.date) === 2009);
},