test-drive
v1.6.0
Published
Opinionated library for writing web component tests
Downloads
386
Readme
Test Drive
Test Drive is an opinionated, yet framework-agnostic collection of tools, matchers and helpers for efficient Test Driven Development of web applications, GUIs and client-side components. Based on existing Open Source projects, as well as original contributions and ideas, it provides not only practical and efficient solutions for writing reliable tests, but also methodological guidelines based on long-term experimentation and hard-won lessons.
Installation
test-drive can be installed via the npm registry:
npm i test-drive --save-dev
If using TypeScript, several @types packages are required as well:
npm i @types/chai @types/sinon @types/sinon-chai @types/chai-dom @types/chai-as-promised --save-dev
test-drive exports sinon and chai via its main entry point. chai's expect is also directly exported, and is pre-loaded with chai-as-promised, chai-dom, sinon-chai, and chai-style assertions.
How to write tests
Locating your DOM parts: selectDOM()
selectDom(container: Element, attrName: string = 'data-automation-id')
Returns DOM selector function for the container
, using attribute attrName
.
DOM selector is a function accepting one or more string identifiers.
Example:
const select = selectDOM(document.body, 'my-id');
const element = select('panel1', 'button-ok');
This code will find, inside the document body, element with attribute "myId" containing word "panel1" and inside it element with the same attribute containing word "button-ok".
element
will be null, if such path cannot be resolved ("button-ok" or
even "panel1" cannot be found).
The function select
will throw an exception, if the path is ambiguous
(e.g., "panel1" contains more than one "button-ok").
The .present()
and .absent()
matchers
Often, components have parts which are sometimes present, sometimes absent, depending on their configuration or state. As there are many possibilities how such "re-appearance" can be implemented, this kit provides a matcher that abstracts such internal implementation away.
Example:
expect(element).to.be.present();
expect(element).to.be.absent();
expect(element).not.to.be.present();
expect(element).not.to.be.absent();
"Presence" is defined as follows:
- "element" is not null
- "element" is an instance of
Element
- some part of "element" has real size (defined as
ClientRect
whose bothwidth
andheight
are greater than zero)
(This definition is inspired by jQuery's :visible
selector, but not
necessarily compliant with it.)
Layout Matchers
Using layout matchers, component developers can implement tests which assert relations between various parts of the component in terms of position in the document. Layout matchers abstract away the actual DOM structure and CSS rules, as they are based solely on absolute location of bounding rectangles. With the right combination of layout matchers, one should be able describe most of spatial relationships within components.
The parts are passed as references to HTMLElement
.
Tests of layout matchers should provide exhaustive examples on how to use the matchers.
Placement
.insideOf(x)
asserts that the subject is completely within the boundaries of element x
.
.outsideOf(x)
asserts the the subject is completely outside the boundaries of element x
.
If the subject is partly inside and partly outside, none of the matchers passes.
Example:
expect(button).to.be.insideOf(panel);
Box Properties
Box properties of an element (width
, height
, left
, top
, right
, bottom
) can be measured
and asserted with numeric matchers, such as:
expect(button1).to.have.width.equal(10);
Elements can also be compared with greaterThan()
, above()
, lessThan()
, below()
, at.least()
and at.most()
:
expect(button1).to.have.height.greaterThan(button2);
At the same time, numeric comparisons will still work:
expect(button1).to.have.height.greaterThan(10);
Note that top
and bottom
will be compared as numbers. So bottom = 50
will still be "below" bottom = 100
, even though
visually it will, of course, appear "above".
Alignment
.horizontallyAligned("left" | "center" | "right, tolerance = 0.0)
.verticallyAligned("top" | "center" | "bottom", tolerance = 0.0)
The alignment matchers assert that all elements within a list are properly aligned with each other, with optional tolerance range.
Example:
expect([button1, button2, button3]).to.be.verticallyAligned('top', 1.5);
Sequence
.inHorizontalSequence({ distance = 0.0, tolerance = 1.0 })
.inVerticalSequence({ distance = 0.0, tolerance = 1.0 })
Asserts that all elements within a list form uninterrupted sequence, one adjacent to the other, without gaps.
Example:
expect([button1, button2, button3]).to.be.inHorizontalSequence({ distance: 10.0 });
Style
via chai-style
.style(styleName, styleValue)
Asserts that element has style attribute with matching value, regardless of browser-specific value.
Example:
expect(button).to.have.style('background-color', 'green');
License
MIT