Conversation
|
@fast-check/ava
fast-check
@fast-check/jest
@fast-check/packaged
@fast-check/poisoning
@fast-check/vitest
@fast-check/worker
commit: |
|
👋 A preview of the new documentation is available at: http://698263bc35bc3c93e91b1856--dubzzz-fast-check.netlify.app |
|
👋 A preview of the new documentation is available at: http://698277b93756ed858197cdc2--dubzzz-fast-check.netlify.app |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6533 +/- ##
=======================================
Coverage 94.85% 94.85%
=======================================
Files 207 207
Lines 5581 5581
Branches 1468 1468
=======================================
Hits 5294 5294
Misses 274 274
Partials 13 13
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
👋 A preview of the new documentation is available at: http://698453cbaa2e8307c23f83fb--dubzzz-fast-check.netlify.app |
|
👋 A preview of the new documentation is available at: http://69848b8b1f8e7b17ac51c57b--dubzzz-fast-check.netlify.app |
|
👋 A preview of the new documentation is available at: http://6984f32937c2d0ecc21c304b--dubzzz-fast-check.netlify.app |
|
👋 A preview of the new documentation is available at: http://6984f48ce54626eb36f5d799--dubzzz-fast-check.netlify.app |
Applied by GitHub Action workflow: PR Format Run ID: 21728949125 Target PR: 6533
|
👋 A preview of the new documentation is available at: http://69850a4637c2d03d9a1c30a7--dubzzz-fast-check.netlify.app |
| // ❌ Screenshot tests on ModalHeader won't make sense alone in many cases. Except if the component is supposed to be publically used. Same for all other internally used components. | ||
| // ✅ BUT testing their logic in an unitary fashion makes sense. | ||
|
|
||
| // ✅ Screenshot tests on Modal makes sense to avoid visual regressions. |
There was a problem hiding this comment.
| // ❌ Screenshot tests on ModalHeader won't make sense alone in many cases. Except if the component is supposed to be publically used. Same for all other internally used components. | |
| // ✅ BUT testing their logic in an unitary fashion makes sense. | |
| // ✅ Screenshot tests on Modal makes sense to avoid visual regressions. | |
| // ✅ Screenshot tests on Modal makes sense to avoid visual regressions. |
…6549) Two new testing recipe references for the `javascript-testing-expert` skill, covering UI component and workflow testing patterns. ### `test-design-system-components.md` - Black-box/integration testing of public DS components - In-browser screenshot tests for visual regression, DOM snapshots as fallback - a11y-first querying (`getByRole`, `getByLabelText`, `getByText` over `getByTestId`) - ARIA attribute verification and keyboard navigation checks - Browser interactivity tests with testing-library fallback ### `test-complex-ui-workflows.md` - Extract logic into pure functions, test with property-based testing - Screenshot tests at macro-component level for key states - Browser-based workflow validation (multi-step forms, dashboards) - Model-based testing section with fast-check `ICommand` pattern for stateful UIs with many interaction paths ```ts // Model-based testing example for complex UI class AddTodoCommand implements fc.ICommand<TodoModel, TodoApp> { constructor(readonly text: string) {} check() { return true; } run(model: TodoModel, real: TodoApp) { model.items.push(this.text); real.addItem(this.text); expect(real.getItems()).toEqual(model.items); } toString() { return `AddTodo(${this.text})`; } } ``` ### `SKILL.md` - Added both references to the Testing recipes table Both docs cross-reference `test-async-code.md`, `test-glue-code.md`, and `property-based-testing.md` where relevant. <!-- START COPILOT CODING AGENT SUFFIX --> <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > Pull request: https://github.com/dubzzz/fast-check/pull/6533/files > > based on this skill https://skills.sh/anthropics/skills/skill-creator and by mimicking how we implemented other references, come up with test-design-system-components explaining how how could test them. recommend in-browser screenshot tests and checks of the interactivity, and to fallback to testing-library when browser testing is not a thing. recommend a11y checks to be ran, to follow the guidelines getByRole and similar that are often the go-to recommandations for testing-library. overall recommend testing design system components (the public ones) in an integration/black box fashion > > also come up with a doc for test-complex-ui-assemblages (replace assemblages by something better). in this one mostly recommend screenshot tests for non visual reg of the macro component. recommend extracting pieces of logics as much as possible to make them easier to test. for remaining logic suggest browser (or testing-library if no browser) to check interactivity. recommend to have a look into model based testing via fast-check, take our doc and examples to document it slightly > > for each of them maybe put a note regarding referring to other pages if async code or complex sync code needs to be tested. </details> <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: dubzzz <5300235+dubzzz@users.noreply.github.com>
|
👋 A preview of the new documentation is available at: http://698512d43c328a5a2c2edf34--dubzzz-fast-check.netlify.app |
No description provided.