| OLD | NEW |
| (Empty) | |
| 1 |
| 2 <!--- |
| 3 |
| 4 This README is automatically generated from the comments in these files: |
| 5 test-fixture.html |
| 6 |
| 7 Edit those files, and our readme bot will duplicate them over here! |
| 8 Edit this file, and the bot will squash your changes :) |
| 9 |
| 10 The bot does some handling of markdown. Please file a bug if it does the wrong |
| 11 thing! https://github.com/PolymerLabs/tedium/issues |
| 12 |
| 13 --> |
| 14 |
| 15 [](https://travis-ci.org/PolymerElements/test-fixture) |
| 16 |
| 17 |
| 18 ##<test-fixture> |
| 19 |
| 20 The `<test-fixture>` element can simplify the exercise of consistently |
| 21 resetting a test suite's DOM. To use it, wrap the test suite's DOM as a template
: |
| 22 |
| 23 ```html |
| 24 <test-fixture id="SomeElementFixture"> |
| 25 <template> |
| 26 <some-element id="SomeElementForTesting"></some-element> |
| 27 </template> |
| 28 </test-fixture> |
| 29 ``` |
| 30 |
| 31 Now, the `<test-fixture>` element can be used to generate a copy of its |
| 32 template: |
| 33 |
| 34 ```html |
| 35 <script> |
| 36 describe('<some-element>', function () { |
| 37 var someElement; |
| 38 |
| 39 beforeEach(function () { |
| 40 document.getElementById('SomeElementFixture').create(); |
| 41 someElement = document.getElementById('SomeElementForTesting'); |
| 42 }); |
| 43 }); |
| 44 </script> |
| 45 ``` |
| 46 |
| 47 Fixtured elements can be cleaned up by calling `restore` on the `<test-fixture>`
: |
| 48 |
| 49 ```javascript |
| 50 afterEach(function () { |
| 51 document.getElementById('SomeElementFixture').restore(); |
| 52 // <some-element id='SomeElementForTesting'> has been removed |
| 53 }); |
| 54 ``` |
| 55 |
| 56 `<test-fixture>` will create fixtures from all of its immediate `<template>` |
| 57 children. The DOM structure of fixture templates can be as simple or as complex |
| 58 as the situation calls for. |
| 59 |
| 60 ## Even simpler usage in Mocha |
| 61 |
| 62 In Mocha, usage can be simplified even further. Include `test-fixture-mocha.js` |
| 63 after Mocha in the `<head>` of your document and then fixture elements like so: |
| 64 |
| 65 ```html |
| 66 <script> |
| 67 describe('<some-element>', function () { |
| 68 var someElement; |
| 69 |
| 70 beforeEach(function () { |
| 71 someElement = fixture('SomeElementFixture'); |
| 72 }); |
| 73 }); |
| 74 </script> |
| 75 ``` |
| 76 |
| 77 Fixtured elements will be automatically restored in the `afterEach` phase of the |
| 78 current Mocha `Suite`. |
| 79 |
| 80 ## Data-bound templates |
| 81 |
| 82 Data-binding systems are also supported, as long as your (custom) template |
| 83 elements define a `stamp(model)` method that returns a document fragment. This |
| 84 allows you to stamp out templates w/ custom models for your fixtures. |
| 85 |
| 86 For example, using Polymer 0.8's `dom-template`: |
| 87 |
| 88 ```html |
| 89 <test-fixture id="bound"> |
| 90 <template is="dom-template"> |
| 91 <span>{{greeting}}</span> |
| 92 </template> |
| 93 </test-fixture> |
| 94 ``` |
| 95 |
| 96 You can pass an optional context argument to `create()` or `fixture()` to pass |
| 97 the model: |
| 98 |
| 99 ```js |
| 100 var bound = fixture('bound', {greeting: 'ohai thurr'}); |
| 101 ``` |
| 102 |
| 103 ## The problem being addressed |
| 104 |
| 105 Consider the following `web-component-tester` test suite: |
| 106 |
| 107 ```html |
| 108 <!doctype html> |
| 109 <html> |
| 110 <head> |
| 111 <title>some-element test suite</title> |
| 112 |
| 113 <link rel="import" href="../some-element.html"> |
| 114 </head> |
| 115 <body> |
| 116 <some-element id="SomeElementForTesting"></some-element> |
| 117 <script> |
| 118 describe('<some-element>', function () { |
| 119 var someElement; |
| 120 |
| 121 beforeEach(function () { |
| 122 someElement = document.getElementById('SomeElementForTesting'); |
| 123 }); |
| 124 |
| 125 it('can receive property `foo`', function () { |
| 126 someElement.foo = 'bar'; |
| 127 expect(someElement.foo).to.be.equal('bar'); |
| 128 }); |
| 129 |
| 130 it('has a default `foo` value of `undefined`', function () { |
| 131 expect(someElement.foo).to.be.equal(undefined); |
| 132 }); |
| 133 }); |
| 134 </script> |
| 135 </body> |
| 136 </html> |
| 137 ``` |
| 138 |
| 139 In this contrived example, the suite will pass or fail depending on which order |
| 140 the tests are run in. It is non-deterministic because `someElement` has |
| 141 internal state that is not properly reset at the end of each test. |
| 142 |
| 143 It would be trivial in the above example to simply reset `someElement.foo` to |
| 144 the expected default value of `undefined` in an `afterEach` hook. However, for |
| 145 non-contrived test suites that target complex elements, this can result in a |
| 146 large quantity of ever-growing set-up and tear-down boilerplate. |
| 147 |
| 148 |
| OLD | NEW |