test-drive-react


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

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().

render(element, container?)

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

cleanup()

Unmounts the root component and removes any container that had been created by the renderer.

Component Drivers

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.:

``tsx
export class TestComponentDriver extends DriverBase {
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.:

`tsx
const { driver } = clientRenderer.render().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.

License

MIT