You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .claude/rules/matterbridge/matterbridge.instructions.md
+12-42Lines changed: 12 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
description: 'How to create MatterbridgeEndpoint instances, register them in Matterbridge plugins, and use the single-class devices exported by the package v. 1.0.0'
2
+
description: 'How to create MatterbridgeEndpoint instances, register them in Matterbridge plugins, and use the single-class devices exported by the package v. 1.0.1'
-`definition` can be a single device type or an array of device types.
67
61
- Use multiple device types when the endpoint needs more than one role, for example `[contactSensor, powerSource]`.
68
62
- Call one of the Basic Information helpers before `registerDevice()`. Without `deviceName`, `serialNumber`, and `uniqueId`, registration fails.
69
-
- Call `addRequiredClusterServers()` at the end of the chain so any required clusters that you did not explicitly create are added automatically.
63
+
- Call `addRequiredClusters()` at the end of the chain so any required clusters (server or client) that you did not explicitly create are added automatically.
70
64
- Use `addOptionalClusterServers()` only when you really want the optional clusters defined by the selected device type(s).
71
65
72
66
## MatterbridgeEndpointOptions
@@ -116,7 +110,7 @@ Important behavior:
116
110
117
111
In plugin code, prefer `this.registerDevice(device)` instead of calling Matterbridge internals directly.
Copy file name to clipboardExpand all lines: .claude/rules/testing/unit-tests.instructions.md
+8-6Lines changed: 8 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,23 +5,24 @@ paths:
5
5
- '**/src/**/*.spec.ts'
6
6
- '**/test/**/*.ts'
7
7
- '**/vitest/**/*.ts'
8
+
- '**/buntest/**/*.ts'
8
9
---
9
10
10
11
# Testing Standards for Unit Tests
11
12
12
13
## 1. Test Framework
13
14
14
-
- Use Jest (with ts-jest) or Vitest as the testing framework for all unit tests.
15
15
- Jest is available in the repository when the file `jest.config.js` exists.
16
16
- Vitest is available in the repository when the file `vite.config.ts` exists.
17
-
- Avoid using both Jest and Vitest in the same project to prevent conflicts. When both are available, prefer Vitest for new tests and consider migrating existing Jest tests to Vitest over time.
18
-
- Jest tests live adjacent to the code being tested with a `.test.ts` suffix or in `test` folders. Follow the existing convention in the repository for test file placement.
19
-
- Vitest tests live adjacent to the code being tested with a `.test.ts` suffix or in `vitest` folders. Follow the existing convention in the repository for test file placement.
17
+
- Bun test is available in the repository when the file `bunfig.toml` exists.
18
+
- Jest tests live in `test` folders. Follow the existing convention in the repository for test file placement.
19
+
- Vitest tests live in `vitest` folders. Follow the existing convention in the repository for test file placement.
20
+
- Bun test tests live in `buntest` folders. Follow the existing convention in the repository for test file placement.
20
21
- Ensure that tests are written in TypeScript and follow the ESM module format.
21
22
22
23
## 2. Test Structure
23
24
24
-
- Organize tests in file name `*.test.ts`adjacent to the code being tested.
25
+
- Organize tests in file name `*.test.ts`in the `test`, `vitest`, or `buntest` folders.
25
26
- Use `describe` blocks to group related tests and `test` blocks for individual test cases.
26
27
27
28
## 3. Test Naming
@@ -47,12 +48,13 @@ paths:
47
48
- Run the relevant full test unit from start to finish rather than assuming isolated single-test execution is reliable.
48
49
- If only one test framework is installed, use `npm run test -- yourTest.test.ts` or `npm run test:coverage -- yourTest.test.ts` when the touched area can be validated by running the full relevant test file.
49
50
- When both Jest and Vitest are installed, use `npm run test -- yourTest.test.ts` for Jest or `npm run test:vitest -- yourTest.test.ts` for Vitest.
51
+
- When Bun test is installed, use `bun test yourTest.test.ts`.
50
52
- Use the existing `tasks.json` test tasks for areas that require grouped test files, custom coverage targets, or custom ignore-pattern handling.
51
53
- Avoid running all tests unnecessarily to save time and tokens.
52
54
53
55
## 8. Test Assertions
54
56
55
-
- Use appropriate Jestor Vitest matchers for assertions (e.g., `toBe`, `toEqual`, `toThrow`).
57
+
- Use appropriate Jest, Vitest, or Bun test matchers for assertions (e.g., `toBe`, `toEqual`, `toThrow`).
56
58
- Ensure that assertions are clear and directly related to the behavior being tested.
0 commit comments