test-fixture - Vaadin Add-on Directory
(no summary available)[![Published on NPM](https://img.shields.io/npm/v/@polymer/test-fixture.svg)](https://www.npmjs.com/package/@polymer/test-fixture)
[![Build status](https://travis-ci.org/PolymerElements/test-fixture.svg?branch=master)](https://travis-ci.org/PolymerElements/test-fixture)
[![Published on webcomponents.org](https://img.shields.io/badge/webcomponents.org-published-blue.svg)](https://webcomponents.org/element/@polymer/test-fixture)
##<test-fixture>
The `` element can simplify the exercise of consistently
resetting a test suite's DOM.
See: [Documentation](https://www.webcomponents.org/element/@polymer/test-fixture).
To use it, wrap the test suite's DOM as a template:
```html
```
Now, the `` element can be used to generate a copy of its
template:
```html
```
Fixtured elements can be cleaned up by calling `restore` on the ``:
```javascript
afterEach(function () {
document.getElementById('SomeElementFixture').restore();
// has been removed
});
```
`` will create fixtures from all of its immediate ``
children. The DOM structure of fixture templates can be as simple or as complex
as the situation calls for.
## Even simpler usage in Mocha
In Mocha, usage can be simplified even further. Include `test-fixture-mocha.js`
after Mocha in the `` of your document and then fixture elements like so:
```html
```
Fixtured elements will be automatically restored in the `afterEach` phase of the
current Mocha `Suite`.
## Data-bound templates
Data-binding systems are also supported, as long as your (custom) template
elements define a `stamp(model)` method that returns a document fragment. This
allows you to stamp out templates w/ custom models for your fixtures.
For example, using Polymer's `dom-bind`:
```html
{{greeting}}
```
You can pass an optional context argument to `create()` or `fixture()` to pass
the model:
```js
var bound = fixture('bound', {greeting: 'ohai thurr'});
```
## The problem being addressed
Consider the following `web-component-tester` test suite:
```html
some-element test suite
```
In this contrived example, the suite will pass or fail depending on which order
the tests are run in. It is non-deterministic because `someElement` has
internal state that is not properly reset at the end of each test.
It would be trivial in the above example to simply reset `someElement.foo` to
the expected default value of `undefined` in an `afterEach` hook. However, for
non-contrived test suites that target complex elements, this can result in a
large quantity of ever-growing set-up and tear-down boilerplate.