https://github.com/polymerelements/test-fixture
https://github.com/polymerelements/test-fixture
Last synced: about 1 year ago
JSON representation
- Host: GitHub
- URL: https://github.com/polymerelements/test-fixture
- Owner: PolymerElements
- Created: 2015-04-15T19:54:33.000Z (about 11 years ago)
- Default Branch: master
- Last Pushed: 2024-12-11T00:26:39.000Z (over 1 year ago)
- Last Synced: 2025-04-13T05:05:50.303Z (about 1 year ago)
- Language: JavaScript
- Size: 808 KB
- Stars: 21
- Watchers: 16
- Forks: 14
- Open Issues: 31
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
[](https://www.npmjs.com/package/@polymer/test-fixture)
[](https://travis-ci.org/PolymerElements/test-fixture)
[](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
describe('<some-element>', function () {
var someElement;
beforeEach(function () {
document.getElementById('SomeElementFixture').create();
someElement = document.getElementById('SomeElementForTesting');
});
});
```
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
describe('<some-element>', function () {
var someElement;
beforeEach(function () {
someElement = fixture('SomeElementFixture');
});
});
```
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
import '../some-element.js';
describe('<some-element>', function () {
var someElement;
beforeEach(function () {
someElement = document.getElementById('SomeElementForTesting');
});
it('can receive property `foo`', function () {
someElement.foo = 'bar';
expect(someElement.foo).to.be.equal('bar');
});
it('has a default `foo` value of `undefined`', function () {
expect(someElement.foo).to.be.equal(undefined);
});
});
```
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.