kudzues/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-04-05 16:36:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs(web): update dev guide (#33815)

Browse Source
This commit is contained in:
Stephen Zhou
2026-03-20 17:23:17 +08:00
committed by GitHub
parent b0566b4193
commit ec8ff89dc1
10 changed files with 206 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
web/docs/test.md
View File

@@ -119,13 +119,11 @@ When assigned to test a **directory/path** (not just a single file), follow thes
Choose based on directory complexity:
1. **Single spec file (Integration approach)** - Preferred for related components
- Minimize mocking - use real project components
- Test actual integration between components
- Only mock: API calls, complex context providers, third-party libs
1. **Multiple spec files (Unit approach)** - For complex directories
- One spec file per component/hook/utility
- More isolated testing
- Useful when components are independent
@@ -139,7 +137,7 @@ When using a single spec file:
- ❌ **DO NOT mock** base components (`@/app/components/base/*`)
- ❌ **DO NOT mock** sibling/child components in the same directory
> See [Example Structure](#example-structure) for correct import/mock patterns.
> See [Example Structure] for correct import/mock patterns.
## Testing Components with Dedicated Dependencies
@@ -185,8 +183,8 @@ Treat component state as part of the public behavior: confirm the initial render
- ✅ When creating lightweight provider stubs, mirror the real default values and surface helper builders (for example `createMockWorkflowContext`).
- ✅ Reset shared stores (React context, Zustand, TanStack Query cache) between tests to avoid leaking state. Prefer helper factory functions over module-level singletons in specs.
- ✅ For hooks that read from context, use `renderHook` with a custom wrapper that supplies required providers.
- ✅ **Use factory functions for mock data**: Import actual types and create factory functions with complete defaults (see [Test Data Builders](#9-test-data-builders-anti-hardcoding) section).
- ✅ If it's need to mock some common context provider used across many components (for example, `ProviderContext`), put it in __mocks__/context(for example, `__mocks__/context/provider-context`). To dynamically control the mock behavior (for example, toggling plan type), use module-level variables to track state and change them(for example, `context/provider-context-mock.spec.tsx`).
- ✅ **Use factory functions for mock data**: Import actual types and create factory functions with complete defaults (see [Test Data Builders] section).
- ✅ If it's need to mock some common context provider used across many components (for example, `ProviderContext`), put it in **mocks**/context(for example, `__mocks__/context/provider-context`). To dynamically control the mock behavior (for example, toggling plan type), use module-level variables to track state and change them(for example, `context/provider-context-mock.spec.tsx`).
- ✅ Use factory functions to create mock data with TypeScript types. This ensures type safety and makes tests more maintainable.
**Rules**:
@@ -363,7 +361,6 @@ describe('ComponentName', () => {
1. **i18n**: Uses global mock in `web/vitest.setup.ts` (auto-loaded by Vitest setup)
The global mock provides:
- `useTranslation` - returns translation keys with namespace prefix
- `Trans` component - renders i18nKey and components
- `useMixedTranslation` (from `@/app/components/plugins/marketplace/hooks`)
@@ -533,16 +530,25 @@ const element = await screen.findByText('Async Content')
Test examples in the project:
- [classnames.spec.ts](../utils/classnames.spec.ts) - Utility function tests
- [index.spec.tsx](../app/components/base/button/index.spec.tsx) - Component tests
- [classnames.spec.ts] - Utility function tests
- [index.spec.tsx] - Component tests
## Resources
- [Vitest Documentation](https://vitest.dev/guide/)
- [React Testing Library Documentation](https://testing-library.com/docs/react-testing-library/intro/)
- [Testing Library Best Practices](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library)
- [Vitest Mocking Guide](https://vitest.dev/guide/mocking.html)
- [Vitest Documentation]
- [React Testing Library Documentation]
- [Testing Library Best Practices]
- [Vitest Mocking Guide]
______________________________________________________________________
---
**Remember**: Writing tests is not just about coverage, but ensuring code quality and maintainability. Good tests should be clear, concise, and meaningful.
[Example Structure]: #example-structure
[React Testing Library Documentation]: https://testing-library.com/docs/react-testing-library/intro
[Test Data Builders]: #9-test-data-builders-anti-hardcoding
[Testing Library Best Practices]: https://kentcdodds.com/blog/common-mistakes-with-react-testing-library
[Vitest Documentation]: https://vitest.dev/guide
[Vitest Mocking Guide]: https://vitest.dev/guide/mocking.html
[classnames.spec.ts]: ../utils/classnames.spec.ts
[index.spec.tsx]: ../app/components/base/button/index.spec.tsx