This challenge is not complete and is not functional
- clone repo
- yarn
- yarn serve
yarn install
: install depenedenciesyarn serve
: run app on localhost:8081yarn build
: build app for productionyarn storybook
: run living styleguideyarn storybook:build
: build living styleguide for productionyarn test:unit
: Run snapshot and regression testsyarn test:report
: Collect test coverage report and view in browseryarn test:watch
: Update test coverage on the flyyarn lint
: Lint application with prettier
We use storybook to bring transparency into the development cycle and to achieve the following:
- Increased velocity
- Streamline the workflow
- Build components in isolation
- Mock hard to reach use cases
- Document use cases as stories
- Share and reuse everything
- Ship with confidence
You can read more about storybook here.
Each component should have a story for each state. For example:
- default
- Empty
- Normalized
- Storybook
- Jest
- addon-storyshots
- storyshots-puppeteer
We use the testing pyramid to ensure we deliver high quality user experiences. We've automated unit and most integration test cases by using jest, storybook and storyshots. Our stories generate tests to cover:
- Unit tests (good coverage)
- Integration tests, visual regression
- End-to-end test, cross-browser visual regression
Having React coupled with Storybook and Storyshots, unlocks a different model: the Diamond model. The diamond model for your UI/App means: little to zero unit tests, massive amount of integration tests, and zero manual tests.
What changed? Integration tests were avoided in the early days because they had a reputation of running slowly; granted — with most technologies this is still very true.
With Jest, React, and Storybook/Storyshots, this is (arguably) no longer the case. No longer must you bring up a browser for each test that leaves its traces in your test environment, or have flaky test suites run and fail randomly, using a not-so-smart test runner that forces you to run everything exactly when you didn’t want to. It’s an era where frontend tooling really does work, and hard becomes easy.
If you already write stories for every component, you already are writing tests, and you just don’t know it yet. Given the thesis above, each of your stories can automatically become a tests:
- Input is your story
- Processing is simply rendering a story (which storybook already does)
- Output is a generated snapshot
And this is what Storyshots does. Storyshots will verify that a React component renders correctly; and if you build multiple stories with a number of different properties then Storyshots can snapshot those as well, and those would be verified on every test run.
Test Type | Level | Subject | Solution | Source |
---|---|---|---|---|
Browser Regression | Integration | Page/Component | Storyshots | Story |
Visual Regression | Integration | Page/Component | Storyshots | Story |
Render | Integration | Page/Component | Storyshots | Story |
Interaction | Unit | Component | Storyshots | Unit Test |
That said, you should definitely keep your “classic” unit tests for logic, library and domain model code. All these things you put in /lib, external packages that deal with your domain model and so on.
You can read more about it here
yarn storybook
, starts storybook at localhost:9009yarn test:unit
, compares updates to image snapshotsyarn test:report
view test coverage report in the browseryarn test:watch
update test coverage on the fly
run yarn storybook
and yarn test:coverage
in seperate terminals to get instant feedback on regression tests