ab21c7f805
* feat: Cal.diy — community-driven MIT-licensed fork of Cal.com This squashed commit contains all Cal.diy changes applied on top of calcom/cal.com main: - Rebrand Cal.com to Cal.diy across the entire codebase - Remove Enterprise Edition (EE) features, license checks, and AGPL restrictions - Switch license from AGPL-3.0 to MIT - Remove docs/ directory (migrated to Nextra at cal.diy) - Remove dead code: org tests, EE tips, platform nav, premium username, SAML/SSO, etc. - Clean up .env.example for self-hosted Cal.diy - Update Docker image references to calcom/cal.diy - Update README, CONTRIBUTING.md, and issue templates for Cal.diy community fork - Add PR welcome bot for Cal.diy contributors - Fix API v2 breaking changes oasdiff ignore entries - Replace Blacksmith CI runners with default GitHub Actions 3893 files changed, 20789 insertions(+), 411020 deletions(-) Co-Authored-By: benny@cal.com <sldisek783@gmail.com> * refactor: remove org-specific /organizations/:orgId endpoints from API v2 atoms controllers (#1701) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * fix: revert Cal.diy Inc to Cal.com, Inc. in license files, copyright notices, and package metadata (#1702) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * rip out org related comments in api v2 --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
---
|
|
title: Mock Implementation Patterns
|
|
impact: MEDIUM
|
|
impactDescription: Poor mocks cause flaky tests and false positives
|
|
tags: testing, mocking, calendar, app-store
|
|
---
|
|
|
|
# Mock Implementation Patterns
|
|
|
|
## Calendar Service Mocks
|
|
|
|
When mocking calendar services in Cal.diy test files, implement the `Calendar` interface rather than adding individual properties from each specific calendar service type (like `FeishuCalendarService`).
|
|
|
|
Since all calendar services implement the `Calendar` interface and are stored in a map, the mock service should also implement this interface to ensure type compatibility.
|
|
|
|
## App-Store Integration Mocks
|
|
|
|
When mocking app-store resources in Cal.diy tests, prefer implementing simpler mock designs that directly implement the required interfaces rather than trying to match complex deep mock structures created with `mockDeep`.
|
|
|
|
This approach is more maintainable and helps resolve type compatibility issues.
|
|
|
|
## General Guidance
|
|
|
|
- For complex mocks that cause type compatibility issues with deep mocks, consider using simpler fake implementations
|
|
- When needed, you can modify other mock files to support your implementation
|
|
- Creative solutions and refactoring to better designs are encouraged when standard mocking causes persistent type errors
|