feat: support DOM snapshot testing

[yannbf]

This PR provides an extra argument to the postRender hook containing the story's inner HTML.
With this it will be possible to do DOM snapshot testing with:

// .storybook/test-runner.js
module.exports = {
  async postRender(page, context, element) {
    expect(element).toMatchSnapshot();
  },
};

📦 Published PR as canary version: 0.1.2--canary.117.f7145f0.0

✨ Test out this PR locally via:

npm install @storybook/test-runner@0.1.2--canary.117.f7145f0.0
# or 
yarn add @storybook/test-runner@0.1.2--canary.117.f7145f0.0

Version

Published prerelease version: v0.1.2-next.0

Changelog

🐛 Bug Fix

• feat: support DOM snapshot testing #117 (@yannbf)
• Add reporting to CI #113 (@yannbf)

⚠️ Pushed to next

• add fake failure for testing purposes (@yannbf)
• chore: add reports when workflow fails (@yannbf)

📝 Documentation

• Updates readme to lock Jest to version 27 #115 (@jonniebigodes)

Authors: 2

• @jonniebigodes
• Yann Braga (@yannbf)

[shilman]

If the HTML is available off the page, why pass it to the hook at all? Instead we could just have a recipe where the user does:

async postRender(page, context) {
  const elementHandler = await page.$("#root")
  const innerHTML = await elementHandler.innerHTML();
  expect(innerHTML).toMatchSnapshot();
}

The benefits are:

1. Our API remains simple
2. We only "pay" to execute that code when it's actually needed, instead of doing it for every render regardless of whether the hooks use it

WDYT?

[yannbf]

If the HTML is available off the page, why pass it to the hook at all? Instead we could just have a recipe where the user does:

async postRender(page, context) {
  const elementHandler = await page.$("#root")
  const innerHTML = await elementHandler.innerHTML();
  expect(innerHTML).toMatchSnapshot();
}

The benefits are:

1. Our API remains simple
2. We only "pay" to execute that code when it's actually needed, instead of doing it for every render regardless of whether the hooks use it

WDYT?

Makes total sense. I updated the PR accordingly.
About the jest-serializer-html lib, WDYT about it? Should we have it as a dependency by default for a seamless experience or have that as a part of a recipe? It's 112.6kB minified.

[shilman]

@yannbf Normally I'd say make the serializer part of a recipe since not all users will actually use this. However, after reading your PR I think it makes more sense to include it for now, because it's zero config now. Great stuff! I think maybe we can revisit this decision later after the test runner is more mature.