chore: add visual-test route

[levithomason]

We currently separately test every example for every component. We have consumed over 50% of our 20,000 images per month in just a few days.

This PR introduces a new route visual-test that renders all the examples for a single component on one page. It also renders an RTL version.

The markup is very minimal, a couple divs and headers to indicate which examples are being rendered. Now, we can just take a single image of this route.

---

http://localhost:8080/visual-test/button

[codecov]

Codecov Report

Merging #106 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #106   +/-   ##
=======================================
  Coverage   88.37%   88.37%           
=======================================
  Files          45       45           
  Lines         757      757           
  Branches      109      109           
=======================================
  Hits          669      669           
  Misses         85       85           
  Partials        3        3

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 62ac7b5...e096aeb. Read the comment docs.

[levithomason]

Bug fix for mergeThemes, see additional tests.

[levithomason]

/cc @miroslavstastny @kuzhelov

[miroslavstastny]

You are still looping over all examples here! That means that if a component has 10 examples, you will trigger the test for the whole component 10 times and end up having 10 same screenshots in screener.io

[levithomason]

Fixed, thanks!

[miroslavstastny]

nit: Before this change mergeComponentVariables(undefined, undefined) returned and empty object, now it returns undefined - as a result if component has no variables, it receives variables=undefined in it's componentStyles(). Not sure this is the best practice.

[levithomason]

This still returns an object because the "initial" value is an object, which is the initial acc value.

I've added a test that asserts this just be sure:

  test('always returns an object', () => {
    expect(mergeThemes(undefined, undefined)).toMatchObject({})
    expect(mergeThemes(null, undefined)).toMatchObject({})
    expect(mergeThemes(undefined, null)).toMatchObject({})
    expect(mergeThemes(null, null)).toMatchObject({})

    expect(mergeThemes({}, undefined)).toMatchObject({})
    expect(mergeThemes(undefined, {})).toMatchObject({})
    expect(mergeThemes({}, {})).toMatchObject({})

    expect(mergeThemes({}, null)).toMatchObject({})
    expect(mergeThemes(null, {})).toMatchObject({})
    expect(mergeThemes({}, {})).toMatchObject({})
  })

[miroslavstastny]

That's true for mergeThemes(), but not for mergeComponentVariables() which is called directly in renderComponent():

expect(mergeComponentVariables(undefined, undefined)()).toMatchObject({})

received value must be an object.
Received: undefined

For that reason, Header component fails to render in the branch. (The fact that it uses a variable and doesn't have any headerVariables is another story, will talk to @kuzhelov about that).

[miroslavstastny]

I like it. The only problem I see is the screener.io diff if anything in the middle changes it's size.
In the screenshot bellow, I removed ButtonExampleContentAndIcon.tsx. This change is correctly detected by screener, but bellow this change, screener detects several layout changes. This can make reviewing changes difficult.

Source: https://screener.io/v2/states/rkGqtccHX.stardust-ui-react/(default)/1024x768/Chrome/button-1-1-0

[levithomason]

The only problem I see is the screener.io diff if anything in the middle changes it's size.

I've fixed the height of each example to 100vh to prevent the offset jitter issues.

[levithomason]

Even with the updates, we will still have lots of breaking changes that are hard to review to due added/removed/renamed example files.

We cannot sort examples by created date without considerable updates to the build. This information would be needed at render time where we only have the Webpack require.context() information. In order to resolve created times, we'd need to pre-build this information or pass it into the view somehow.

For now, screener is still running despite having maxed out our quota. Also, I have saved many test cycles by changing the CI config to skip testing redundant and stale commits.

At this point, I think it is worth it to keep our current setup and assess the cost of the service instead of degrading our ability to rely on it.

[levithomason]

No longer needed. We now have unlimited image comparisons on Screener.io 🎉