CSS Unit Testing

CSS Unit Testing

You could use Selenium, which is a web testing framework. This way you could assert what styles are to be applied to elements in the DOM etc.

Selenium

Otherwise, not sure what your aim is. Unit testing is, as the name suggests, testing 'Units', and to me, this only makes sense with code, not css.

How to test styling using Jest

I agree with Dominik. Jest is good for testing properties of your rendered HTML. Unless the styling is within the HTML (inline styling), Jest will not see it (as you have pointed out). The deepest you could test without in-lining the styles is to verify that it has a proper class name.

Maybe a test framework that runs in a browser like Cypress? Have a read of visual testing with Cypress.

How to access style present in .css file in angular unit test

I know I am late here but you can try. It will work 100%

  it('should have green background', () => {
    const e = fixture.debugElement.query(By.css(".divAllAllowedIPs")).nativeElement;
    expect(getComputedStyle(e).backgroundColor).toEqual('rgb(0, 128, 0)');
  });

I hope it'll help others as well who are looking for something similar question

CSS specificity testing

The method I settled with is to use getComputedStyle to get the style with "highest priority". In the css I add a "tag" to the content property. In jasmine I then check if the desired tag is the computedStyle. (I will extend this in scss so that the content property is set by a mixin if test mode is used and not set in production.) This only makes a unit test for the class of highest priority, but not for the second highest etc.

Below is a tests to illustrate the example (only the first and last should pass).

// specs codedescribe("CSS", function() {  it("Div element of class test should be handled by .test", () => {    const testdiv = document.getElementById("testdiv")    m = window.getComputedStyle(testdiv).getPropertyValue("content");        expect(m).toEqual('".test"');  });
 it("Div element of class test should be handled by div", () => {    const testdiv = document.getElementById("testdiv")    m = window.getComputedStyle(testdiv).getPropertyValue("content");        expect(m).toEqual('"div"');  });
 it("Div element should be handled by .test", () => {    const testdiv = document.getElementById("testdiv2")    m = window.getComputedStyle(testdiv).getPropertyValue("content");        expect(m).toEqual('".test"');  });
 it("Div element of class test should be handled by div", () => {    const testdiv = document.getElementById("testdiv2")    m = window.getComputedStyle(testdiv).getPropertyValue("content");        expect(m).toEqual('"div"');  });
});

// load jasmine htmlReporter(function() {  var env = jasmine.getEnv();  env.addReporter(new jasmine.HtmlReporter());  env.execute();}());

.test {    content: '.test';}
div {  content: 'div';}

<script src="https://cdn.jsdelivr.net/jasmine/1.3.1/jasmine.js"></script><script src="https://cdn.jsdelivr.net/jasmine/1.3.1/jasmine-html.js"></script><link href="https://cdn.jsdelivr.net/jasmine/1.3.1/jasmine.css" rel="stylesheet"/><div class="test" id="testdiv">TestDiv</div><div id="testdiv2">TestDiv</div>

Unit testing css with angular

Something like this...

1. Exposed the myDiv publicly

2. Setup the testbed for the component (usually added by default)

3. Add

component.myFunct();

expect(component.myDiv.nativeElement.style.height).toBe(500);

How do you test the functionality of less CSS with Jest?

You can read more on how Jest handles mocking CSS modules in the Jest docs. You could perhaps write your own module name mapper or custom transform to load and process the Less files. However, you'd have to figure out how to actually inject the CSS into the code under test (that's something that Webpack normally handles). Something like jest-transform-css might do this.

Personally, I'd just test whether the CSS class is present, like @jonrsharpe suggests. Think of it from the perspective of the test pyramid: your Jest tests should likely be focused at the unit test level, with an emphasis on speed and simplicity. Unit tests are ideally fast enough that you can run them nearly instantly, whenever you save a file; adding the complexity to parse and insert Less CSS may work against that.

It's okay if the unit tests don't test the entire stack; you have other tests, higher up in the pyramid, to do this. For example, you could have a handful of Cypress tests that run your app in the actual browser and verify that a couple of controls are actually hidden, then it should be safe to assume that (1) Jest validating all controls set the correct class plus (2) Cypress validating that a few controls with the correct class are correctly hidden means that (3) all controls are correctly hidden.

To help make your tests more self-documenting, and to make them easier to maintain if you ever change how controls are shown and hidden, you can use Jest's expect.extend to make your own matcher. Perhaps something like this (untested):

expect.extend({
  toBeVisibleViaCss(received) {
    const pass = !received.classList.contains('content-hidden');
    const what = pass ? 'not visible' : 'visible';
    return {
      message: () => `expected ${received} to be ${what}`,
      pass,
    };
  },
});

First of all, is this good practice? I have always (in most cases) shown and hidden components using a boolean to add or remove it from the dom (this is also easy to test).

Hiding components via CSS is certainly not what I'm used to. Without knowing your codebase, I'd wonder if the developers were used to previous jQuery-style approaches of hiding via manipulating the class lists. The main advantage I'm aware of keeping components always rendered is that you can animate their transitions if you want to. I'm not sure how performance compares; the browser might find it faster to toggle a CSS class than to add or remove an element, but removing the element means that React has less to render, which could help performance.

---

Related Topics