You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: packages/@css-blocks/ember-app/README.md
+35
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,41 @@ The following options can be passed as options to the `css-blocks` property in y
32
32
*`broccoliConcat` - Options that control the behavior of broccoli-concat, which is used to concatenate CSS files together by ember-app during postprocess. If this is set to false, broccoli-concat will *not* run and you'll need to add additional processing to add the CSS Blocks compiled content to your final CSS build artifact.
33
33
*`appClasses` - List of classes that are used by application CSS and might conflict with the optimizer. You should add any short class names (~5 characters) to this list so the optimizer doesn't use these when building the CSS Blocks compiled output. This is a convenience alias for `optimization.rewriteIdents.omitIdents.class[]`. It has no effect if optimization is disabled.
34
34
35
+
## Testing
36
+
Once you have integrated this addon within an ember application, all your CSS classnames are going to look very different from what they did in the block files that you had originally written and the output CSS classnames will vary across builds and across different machines. This is done intentionally to ensure that you don't use any CSS classname selectors in any of the tests and that your tests remain robust across executions. Not to mention, even the number of classes on an element can be entirely different after all the CSS has been optimized using opticss.
37
+
38
+
In order to faciliate testing in such an environment, this ember addon provides a utility method called `setupCSSBlocksTest()` that that exposes the CSS blocks service that can in turn be used to query the existence of certain classes on your elements.
39
+
40
+
Note: `setupCSSBlocksTest()` has been written to work with `ember-qunit` and `ember-mocha`.
41
+
42
+
### Test setup and usage
43
+
- In your integration or acceptance tests, call `setupCSSBlocksTest()` declaring any tests. Ensure that `setupCSSBlocksTest()` is called *after*`setupTest|setupRenderingTest|setupApplicationTest` for the setup to work as desired.
44
+
**Note: `setupCSSBlocksTest` is exposed within a service on the application's namespace and will have to be imported as such**
45
+
```js
46
+
import { setupCSSBlocksTest} from '<appName>/services/css-blocks-test-support';
47
+
```
48
+
- After this, the css-blocks service is available to the test via `this.cssblocks`
49
+
- The test service primarily exposes a single API function, `this.cssBlocks.getBlock(<pathToBlock>, <blockName>)` that takes in a path to the block file and the an optional blockName. If the blockName isn't specified, the default block for the block file is returned. The <blockPath> begin with either the appName, the addon name (if its from an in-repo addon) or by the engine's name(in the case of an in-repo engine) that it is a part of. `getBlock()` returns a reference to the runtime CSS block which can be queried for styles within the block using `.style(<styleName>)`.
50
+
- The element can then assert whether a certain style is present on it or not using `element.classList.contains()`
0 commit comments