Opinionated library for Test-Driven Development of React components, extending Test Drive and providing its DOM parts lookup, presence/absence matchers and event triggering layout matchers.
In addition, it reexports React simulate testing utility and integrated renderer
ClientRenderer
provides a utility for rendering React components in consistent
and convenient way. It creates the holding container, if necessary, with uniform positioning,
automatically binds to it all important Test Drive helper functions, and proivides clean-up
mechanism.
For a typical use, see the end-to-end test.
The renderer is created simply by invoking new ClientRenderer()
.
Renders the element
React component. If container
is not specified, a new one is created.
Returns RenderingContext
with following fields:
container
result
- rendered root component (either DOM Element or React component instance)select
- DOM selector pre-bound to the container
Unmounts the root component and removes any container that had been created by the renderer.
Test Drive React provides additional layer of abstraction over the basic assertion tools. In order to keep the intended behavior of a component separated from the actual implementation (DOM structure, particular DOM events, etc.), every component should provide it's "driver". Component driver translates meaningful actions and getters into specific DOM details.
All drivers should extend the DriverBase
class. The basic (and recommended) way of creating drivers is to use
.withDriver(DriverClass)
method which is part of the RenderingContext
interface.
For example, consider a TestComponent
. There should be always
relevant implementation of its driver, e.g.:
export class TestComponentDriver extends DriverBase<HTMLElement> {
static ComponentClass = TestComponent;
get samplePart() {
return this.ensuredSelect('SAMPLE_PART') as HTMLDivElement;
}
doAction() {
this.root.click();
}
}
The ComponentClass
points to the component for which is the driver relevant. It is used by the
ClientRenderer
for validation of a component/driver match during the rendering. (This validation
is intended to prevent using a wrong driver on top of a DOM generated by a component.)
The getter .samplePart
provides access (via data-automation-id
) to specific parts of
the component's shadow DOM, while keeping this detail encapsulated. Similarly,
the .doAction()
method represents specific methods, while keeping the technicalities (event type)
private.
The driver then should be instantiated and used through ClientRenderer
, e.g.:
const { driver } = clientRenderer.render(<TestComponent />).withDriver(TestComponentDriver);
expect(driver.samplePart).to.be.present();
Note that the .withDriver()
function returns RenderingContextWithDriver
, which has following
members:
driver
- instance of the component driver
In the case of composite components, the drivers should mirror their structure as well. .samplePart
in
the above example should, therefore, reference another (relevant) component driver, rather than plain DOM Element,
if it corresponds to custom component.
MIT