-
Notifications
You must be signed in to change notification settings - Fork 221
Testing best practices
Add more best practices here!
Constants that are used in tests, such as element sizes or CSS class names or other string
s or number
s, should always be factored out into variables. This practice prevents cases where typos cause tests to pass when they shouldn't:
In the above example, the mistyped class name causes the select()
call to find nothing, meaning the later assert()
will always pass.
it("value()", () => { ... }); // doesn't explain what's being tested
it("can get and set value()", () => { ... }); // good: reads like a sentence, explains what the test does
(<any> assert).throws(() => c.foo(), Error, "", "The reason"); // bad
(<any> assert).throws(() => c.foo(), Error, "Error message", "The reason"); // good
The reason for that is that if we are expecting an error, but we are getting a different error, we should catch that as unexpected behavior. The reason against this change was code fragility (if we change the error message we don't want to duplicate the code, but we already do that for any of the behavior change in code that reflects into tests)
for (let i = 0; i < n; i++) {
assert.strictEqual(array[i], expected, `object ${i} has expected property`); // template string
}
Doing so makes it easier to debug where in the loop things went wrong. This should also be used in forEach()
loops.
assert.isTrue(a > b); // does not produce a helpful error message
assert.operator(a, ">", b); // better
The "length" of a D3 Selection
is always 1, regardless of how many elements are in it:
d3.select().length; // 1, not 0
The correct way to check the size of the Selection
is to assert that its size()
is equal to a particular value:
assert.strictEquals(selection.size(), expectedSize, message);
Use
whateverSelection.selectAll("line").each(function() {
let lineSelection = d3.select(this); // "this" refers to the DOM node inside the loop
});
Instead of hacky stuff like
whateverSelection.selectAll("line")[0].forEach((line) => {
let lineSelection = d3.select(line);
});
let edges = dbl.content().selectAll("line"); // this selection
assert.strictEqual(edges.size(), 4, "the edges of a rectangle are drawn"); // check here
edges.each(function() { // otherwise asserts here do not get called
...
}
Use assert.closeTo
in scenarios where we are checking pixels against data values and in float arithmetic.
PhantomJS doesn't measure elements in the same way as real browsers: it considers the size of <svg>
s based on their content rather than the <svg>
's actual width and height. Append a <rect>
and measure that, or measure component.background()
instead.
That is because if something goes wrong with the test, we want to have the visual.
- Obviously don't use === because that is reference equality
- getTime has the advantage that it explodes for non-dates
- Use
plot.content()
instead ofplot._renderArea
- Make sure we use the
it()
semantically. It should read like a sentence. For exampleit("does not draw rectangles for invalid data points")
instead ofit("data points that are not valid, do not draw rectangles on the plot")
These are just suggestions of best practices, slowly move them upwards as people agree. In add proposer & agreers to each to have a sense of what is okay
- Top level describes should act as category delimiters and should not have beforeEach(). That is because sometime we want to add a new, totally unrelated test to some category (say Plots.Line) and the beforeEach() does not make sense. Top Level means the title of the file (so for example "Plots" and "RectanglePlot" will be top level) (@acioara)