@c8y/websdk 1023.81.2 → 1023.82.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +111 -0
- package/dist/ng-add/ai-tools-configure.d.ts +10 -0
- package/dist/ng-add/ai-tools-configure.js +318 -0
- package/dist/ng-add/ai-tools-configure.js.map +1 -0
- package/dist/ng-add/index.js +60 -0
- package/dist/ng-add/index.js.map +1 -1
- package/dist/ng-add/ng-add.model.d.ts +1 -0
- package/dist/templates/ai-configs/claude/CLAUDE.md +98 -0
- package/dist/templates/ai-configs/claude/rules/e2e-tests.instructions.md +187 -0
- package/dist/templates/ai-configs/claude/rules/frontend.instructions.md +251 -0
- package/dist/templates/ai-configs/claude/rules/unit-tests.instructions.md +172 -0
- package/dist/templates/ai-configs/cursor/cursor.mdc +98 -0
- package/dist/templates/ai-configs/cursor/rules/e2e-tests.instructions.md +187 -0
- package/dist/templates/ai-configs/cursor/rules/frontend.instructions.md +251 -0
- package/dist/templates/ai-configs/cursor/rules/unit-tests.instructions.md +172 -0
- package/dist/templates/ai-configs/gemini/GEMINI.md +98 -0
- package/dist/templates/ai-configs/gemini/rules/e2e-tests.instructions.md +181 -0
- package/dist/templates/ai-configs/gemini/rules/frontend.instructions.md +247 -0
- package/dist/templates/ai-configs/gemini/rules/unit-tests.instructions.md +166 -0
- package/dist/templates/ai-configs/github/copilot-instructions.md +98 -0
- package/dist/templates/ai-configs/github/instructions/e2e-tests.instructions.md +187 -0
- package/dist/templates/ai-configs/github/instructions/frontend.instructions.md +251 -0
- package/dist/templates/ai-configs/github/instructions/unit-tests.instructions.md +172 -0
- package/dist/templates/ai-configs/jetbrains/guidelines.md +98 -0
- package/dist/templates/ai-configs/jetbrains/rules/e2e-tests.instructions.md +181 -0
- package/dist/templates/ai-configs/jetbrains/rules/frontend.instructions.md +247 -0
- package/dist/templates/ai-configs/jetbrains/rules/unit-tests.instructions.md +166 -0
- package/dist/templates/ai-configs/windsurf/guidelines.md +98 -0
- package/dist/templates/ai-configs/windsurf/rules/e2e-tests.instructions.md +187 -0
- package/dist/templates/ai-configs/windsurf/rules/frontend.instructions.md +251 -0
- package/dist/templates/ai-configs/windsurf/rules/unit-tests.instructions.md +172 -0
- package/package.json +3 -2
|
@@ -0,0 +1,247 @@
|
|
|
1
|
+
|
|
2
|
+
## Persona
|
|
3
|
+
|
|
4
|
+
You are a senior Angular developer working on a **Cumulocity IoT application**. You leverage the latest Angular features: signals, standalone components, and new control flow syntax. Performance and consistency are paramount.
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Resources
|
|
9
|
+
|
|
10
|
+
- Angular docs: https://angular.dev/
|
|
11
|
+
- Angular style guide: https://angular.dev/style-guide
|
|
12
|
+
- Angular signals: https://angular.dev/guide/signals
|
|
13
|
+
- Cumulocity Web SDK / Codex: https://cumulocity.com/codex/
|
|
14
|
+
- Tutorial examples: https://github.com/Cumulocity-IoT/tutorial
|
|
15
|
+
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## Before You Code
|
|
19
|
+
|
|
20
|
+
1. **Check for existing patterns** — search the codebase for similar components or services before creating new ones. Check `@c8y/ngx-components` exports and [Codex](https://cumulocity.com/codex) (see main instructions for the full mandatory workflow).
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Critical Violations
|
|
25
|
+
|
|
26
|
+
These are the highest-severity issues — NEVER introduce them:
|
|
27
|
+
|
|
28
|
+
- **Unmanaged subscriptions** — every `.subscribe()` must have `takeUntilDestroyed()`, `takeUntil()`, or use `async` pipe
|
|
29
|
+
- **Empty catch blocks** — propagate, display via `AlertService.danger()`, or comment why swallowed
|
|
30
|
+
- **Committed secrets** — no API keys, tokens, passwords, or tenant-specific URLs in source
|
|
31
|
+
- **Dynamic gettext()** — `gettext()` must receive a static string literal; dynamic strings break the entire translation pipeline
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Components
|
|
36
|
+
|
|
37
|
+
- All new components must be **standalone** — do not set `standalone: true` explicitly (default since Angular 19+)
|
|
38
|
+
- Set `changeDetection: ChangeDetectionStrategy.OnPush` in all `@Component` decorators
|
|
39
|
+
- Keep components small — extract when template exceeds ~150 lines or class exceeds ~200 lines
|
|
40
|
+
- Components focus on presentation; extract business logic, data mapping, and SDK calls to dedicated services
|
|
41
|
+
- Use `readonly` for properties that should not change
|
|
42
|
+
- Use `input()` instead of `@Input`, `output()` instead of `@Output`, `viewChild()` instead of `@ViewChild`
|
|
43
|
+
- Do **not** use `@HostBinding` or `@HostListener` — use the `host` object in decorators
|
|
44
|
+
- Use `NgOptimizedImage` for static images (does not work for inline base64)
|
|
45
|
+
- Prefer Reactive forms over template-driven forms
|
|
46
|
+
- Define model interfaces and constants in **dedicated files** (`models.ts`, `types.ts`), not inside component files
|
|
47
|
+
- Keep JSDoc comments in sync with method signatures — out-of-sync documentation is worse than none
|
|
48
|
+
- Use strict type checking where available per package
|
|
49
|
+
- Split into `.ts`, `.html`, and `.scss` files. Use `c8y` prefix for component selectors
|
|
50
|
+
|
|
51
|
+
### Example
|
|
52
|
+
|
|
53
|
+
```ts
|
|
54
|
+
import { ChangeDetectionStrategy, Component, signal } from '@angular/core';
|
|
55
|
+
|
|
56
|
+
@Component({
|
|
57
|
+
selector: 'c8y-example-component',
|
|
58
|
+
templateUrl: './example.component.html',
|
|
59
|
+
changeDetection: ChangeDetectionStrategy.OnPush
|
|
60
|
+
})
|
|
61
|
+
export class ExampleComponent {
|
|
62
|
+
protected readonly isServerRunning = signal(true);
|
|
63
|
+
|
|
64
|
+
toggleServerStatus() {
|
|
65
|
+
this.isServerRunning.update(v => !v);
|
|
66
|
+
}
|
|
67
|
+
}
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
```html
|
|
71
|
+
<section class="container">
|
|
72
|
+
@if (isServerRunning()) {
|
|
73
|
+
<span>{{ 'Yes, the server is running' | translate }}</span>
|
|
74
|
+
} @else {
|
|
75
|
+
<span>{{ 'No, the server is not running' | translate }}</span>
|
|
76
|
+
}
|
|
77
|
+
<button (click)="toggleServerStatus()">{{ 'Toggle Server Status' | translate }}</button>
|
|
78
|
+
</section>
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Templates
|
|
84
|
+
|
|
85
|
+
- Use **native control flow** (`@if`, `@for`, `@switch`) — `*ngIf`, `*ngFor`, `*ngSwitch` are **forbidden**
|
|
86
|
+
- Do **not** use `ngClass` or `ngStyle` — use `[class.x]` and `[style.x]` bindings
|
|
87
|
+
- Do **not** import `CoreModule` in standalone components
|
|
88
|
+
- Use `@let` to avoid repeating expressions
|
|
89
|
+
- Use `async` pipe for observables in templates
|
|
90
|
+
- `@for` track: use `item.id` or meaningful property; only `$index` for readonly primitives
|
|
91
|
+
- Keep templates simple — no method calls in bindings (except pipes), no complex logic
|
|
92
|
+
- Do not assume globals like `new Date()` are available in templates
|
|
93
|
+
- Import pipes explicitly when used in a template
|
|
94
|
+
- Use paths relative to the component `.ts` file for external templates/styles
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
## State Management & Subscriptions
|
|
99
|
+
|
|
100
|
+
- **Signals** for local synchronous state; `computed()` for derived state
|
|
101
|
+
- **RxJS/Promises** for async operations and API calls — don't mix paradigms in one use case
|
|
102
|
+
- Do **not** use `mutate` on signals — use `update` or `set`
|
|
103
|
+
- Do **not** run long-lived async (polling, intervals) in components — extract to services
|
|
104
|
+
- Always unsubscribe: `takeUntilDestroyed()`, `takeUntil()`, or `async` pipe — never bare `.unsubscribe()` without `ngOnDestroy`
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## Dependency Injection & Services
|
|
109
|
+
|
|
110
|
+
- Use **one** DI pattern per file — don't mix constructor injection and `inject()` in the same file
|
|
111
|
+
- `providedIn: 'root'` only for global singletons — scope to components/features when possible
|
|
112
|
+
- Use `@c8y/client` for all Cumulocity REST calls — never `HttpClient` directly
|
|
113
|
+
- Lazy-load feature routes and C8Y widget/plugin modules
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Styling
|
|
118
|
+
|
|
119
|
+
- **Always use design tokens** — never hardcode colors (`#hex`, `rgb()`)
|
|
120
|
+
- `var(--brand-primary, var(--c8y-brand-primary))`
|
|
121
|
+
- Common tokens: `--c8y-brand-primary`, `--c8y-root-component-color-*`, `--c8y-root-component-background-*`, `--c8y-root-component-border-color`
|
|
122
|
+
- Prefer Cumulocity utility classes over custom CSS
|
|
123
|
+
- Avoid `::ng-deep` — use component encapsulation or design tokens
|
|
124
|
+
- Don't use inline styles
|
|
125
|
+
- Use SCSS for new files
|
|
126
|
+
- Reference: https://cumulocity.com/codex/design-system/design-tokens/overview
|
|
127
|
+
|
|
128
|
+
### Utility Class Quick Reference
|
|
129
|
+
|
|
130
|
+
**Spacing:** `m-{side}-{amount}` / `p-{side}-{amount}` — sides: `t`, `r`, `b`, `l` or omit; amounts: 4, 8, 16, 24, 32, 40
|
|
131
|
+
|
|
132
|
+
**Layout:** `d-flex` (row), `d-col` (column) | `j-c-{start|center|end|between|around|evenly}` | `a-i-{start|center|end|stretch}` | `gap-{4|8|16}`
|
|
133
|
+
|
|
134
|
+
**Flex items:** `flex-grow`, `flex-no-shrink`, `flex-auto`, `fit-w`, `fit-h`, `min-width-0`, `min-height-0`
|
|
135
|
+
|
|
136
|
+
**Width/height:** `max-width-100`, `min-width-100`, `max-height-inherit`
|
|
137
|
+
|
|
138
|
+
**Position:** `p-relative`, `p-absolute`, `p-fixed`, `p-sticky`
|
|
139
|
+
|
|
140
|
+
**Text:** `text-left`, `text-center`, `text-right`, `text-pre-wrap`, `text-break-word`, `text-truncate`, `text-truncate-wrap`
|
|
141
|
+
|
|
142
|
+
**Display:** `d-flex`, `d-inline-flex`, `d-col`, `d-block`, `d-inline`, `d-inline-block`, `d-grid`, `d-contents`, `hidden`, `invisible`, `sr-only` | Responsive: `-xs`, `-sm`, `-md`, `-lg`
|
|
143
|
+
|
|
144
|
+
**Icons:** `[c8yIcon]="'icon-name'"` | sizes: `icon-16`, `icon-20`, `icon-32` | decorative: `aria-hidden="true"`
|
|
145
|
+
|
|
146
|
+
---
|
|
147
|
+
|
|
148
|
+
## Internationalization
|
|
149
|
+
|
|
150
|
+
- **Templates:** `{{ 'Text' | translate }}` for simple strings
|
|
151
|
+
- **Templates (conditional):** prefer `@let label = 'Text' | translate;` for conditional or repeated translations. `gettext()` in templates is also valid if exposed as a component property and piped through `| translate`
|
|
152
|
+
- **TypeScript:** `translateService.instant(gettext('Text'))` — `gettext()` marks for extraction only
|
|
153
|
+
- **Placeholders:** `{{ 'Result: {{count}}' | translate: { count: value } }}`
|
|
154
|
+
- Every user-visible string must be wrapped
|
|
155
|
+
- Reference: https://cumulocity.com/codex/components/application-and-system/internationalization/overview
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## Error Handling
|
|
160
|
+
|
|
161
|
+
- **Never leave catch blocks empty** — propagate, display via `AlertService.danger()` with translations, or comment why swallowed
|
|
162
|
+
- API failures must be both logged to console AND displayed to the user
|
|
163
|
+
|
|
164
|
+
---
|
|
165
|
+
|
|
166
|
+
## Accessibility
|
|
167
|
+
|
|
168
|
+
WCAG 2.1 Level AA compliance is **mandatory** for all UI work.
|
|
169
|
+
|
|
170
|
+
### Semantic HTML & Structure
|
|
171
|
+
|
|
172
|
+
- Use semantic elements (`<nav>`, `<main>`, `<section>`, `<article>`, `<aside>`, `<header>`, `<footer>`) — never `<div>` soup
|
|
173
|
+
- Heading levels (`<h1>`–`<h6>`) must follow a logical hierarchy — never skip levels for styling
|
|
174
|
+
- Use `<button>` for actions and `<a>` for navigation — never `<div (click)>` or `<span (click)>`
|
|
175
|
+
- Lists of items must use `<ul>`/`<ol>`/`<li>` — not styled divs
|
|
176
|
+
- Tables must have `<th>` with `scope` attributes; use `<caption>` for table purpose
|
|
177
|
+
|
|
178
|
+
### Keyboard Operability (2.1.1, 2.1.2, 2.1.4)
|
|
179
|
+
|
|
180
|
+
- All interactive elements must be reachable and operable via keyboard alone
|
|
181
|
+
- Custom interactive elements need `tabindex="0"` and key event handlers (`Enter`, `Space`, `Escape`, arrow keys as appropriate)
|
|
182
|
+
- **No keyboard traps** — focus must always be escapable (modals must return focus to trigger on close)
|
|
183
|
+
- Manage focus programmatically on route changes and after dynamic content insertion
|
|
184
|
+
- Character key shortcuts (single letter) must be remappable, disableable, or only active on focus
|
|
185
|
+
|
|
186
|
+
### Focus Management
|
|
187
|
+
|
|
188
|
+
- Focus order must follow a logical reading sequence (`tabindex` > 0 is **forbidden**)
|
|
189
|
+
- Focus must be visible at all times — never `outline: none` without a visible replacement
|
|
190
|
+
- Trap focus inside modals/dialogs while open; restore focus to trigger element on close
|
|
191
|
+
- Use `cdkTrapFocus` or `cdkFocusInitial` from `@angular/cdk/a11y` for focus trapping
|
|
192
|
+
- After dynamic content changes (route navigation, drawer open/close), move focus to the new content
|
|
193
|
+
|
|
194
|
+
### Color & Contrast (1.4.1, 1.4.3, 1.4.11)
|
|
195
|
+
|
|
196
|
+
- **Text contrast:** minimum 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold)
|
|
197
|
+
- **Non-text contrast:** UI components and graphical objects need minimum 3:1 contrast against adjacent colors
|
|
198
|
+
- **Never use color alone** to convey information — always pair with text, icons, or patterns (e.g., error states need icon + color + text, not just red)
|
|
199
|
+
- Use design tokens exclusively — they are pre-validated for contrast compliance, never add custom colors
|
|
200
|
+
|
|
201
|
+
### Forms & Input (1.3.5, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
|
|
202
|
+
|
|
203
|
+
- Every form control must have a visible `<label>` associated via `for`/`id` — never placeholder-only labels
|
|
204
|
+
- Use `autocomplete` attributes on fields collecting personal data (`name`, `email`, `tel`, `street-address`, etc.)
|
|
205
|
+
- Error messages must: identify the field in error, describe the error, and suggest correction
|
|
206
|
+
- Display errors with `role="alert"` or `aria-live="assertive"` so screen readers announce them
|
|
207
|
+
- Group related controls with `<fieldset>` and `<legend>`
|
|
208
|
+
- Required fields must be marked with `aria-required="true"` and a visible indicator
|
|
209
|
+
|
|
210
|
+
### Images & Icons (1.1.1)
|
|
211
|
+
|
|
212
|
+
- Informative images: `alt` text describing content or function
|
|
213
|
+
- Decorative images/icons: `aria-hidden="true"` and empty `alt=""`
|
|
214
|
+
- Icon-only buttons must have `aria-label` or visually hidden text: `<button aria-label="{{ 'Delete item' | translate }}"><i [c8yIcon]="'minus-circle'" aria-hidden="true"></i></button>`
|
|
215
|
+
- Complex images (charts, diagrams): provide text alternative via `aria-describedby` pointing to a description
|
|
216
|
+
|
|
217
|
+
### Dynamic Content & Live Regions (4.1.3)
|
|
218
|
+
|
|
219
|
+
- Status messages (success, info, warnings) must use `role="status"` or `aria-live="polite"`
|
|
220
|
+
- Urgent messages (errors, alerts) must use `role="alert"` or `aria-live="assertive"`
|
|
221
|
+
- Loading states: announce start and end — e.g., `aria-busy="true"` on the container, announce completion
|
|
222
|
+
- Content that updates without page reload must notify assistive technology
|
|
223
|
+
- Never auto-update content faster than the user can read it; provide pause/stop controls for auto-rotating content
|
|
224
|
+
|
|
225
|
+
### Text & Content (1.4.4, 1.4.10, 1.4.12, 1.4.13)
|
|
226
|
+
|
|
227
|
+
- Text must be resizable up to 200% without loss of content or functionality
|
|
228
|
+
- Content must reflow at 320px viewport width without horizontal scrolling
|
|
229
|
+
- No loss of content when users override text spacing (line height 1.5x, letter spacing 0.12em, word spacing 0.16em)
|
|
230
|
+
- Content revealed on hover/focus (tooltips) must be: dismissible (Esc), hoverable (mouse can reach it), and persistent (stays until dismissed)
|
|
231
|
+
|
|
232
|
+
### ARIA Usage
|
|
233
|
+
|
|
234
|
+
- **First rule of ARIA:** don't use ARIA if a native HTML element provides the semantics (`<button>` over `<div role="button">`)
|
|
235
|
+
- Use `aria-label` or `aria-labelledby` for elements without visible text labels
|
|
236
|
+
- Use `aria-describedby` for supplementary descriptions (help text, constraints)
|
|
237
|
+
- Use `aria-expanded`, `aria-controls`, `aria-haspopup` for disclosure widgets
|
|
238
|
+
- Custom widgets (tabs, trees, comboboxes) must implement the full [WAI-ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/) keyboard and role pattern
|
|
239
|
+
- Use `aria-current="page"` for active navigation links
|
|
240
|
+
|
|
241
|
+
### Testing Checklist
|
|
242
|
+
|
|
243
|
+
- **Keyboard-only:** tab through entire page, operate every control, escape every modal
|
|
244
|
+
- **Screen reader:** test critical flows with VoiceOver (macOS) — ensure all content is announced
|
|
245
|
+
- **Zoom:** verify layout at 200% zoom and 320px viewport
|
|
246
|
+
- **Color:** inspect with simulated color-blindness (DevTools → Rendering → Emulate vision deficiencies)
|
|
247
|
+
- **Automated:** run `axe-core` or Lighthouse accessibility audit — zero violations is the baseline, not the goal
|
|
@@ -0,0 +1,166 @@
|
|
|
1
|
+
|
|
2
|
+
# Unit Testing Guide
|
|
3
|
+
|
|
4
|
+
## Overview
|
|
5
|
+
Unit tests use Jest with TestBed for Angular component setup and jest.fn() for mocking services.
|
|
6
|
+
|
|
7
|
+
# Common
|
|
8
|
+
|
|
9
|
+
## Test File Location
|
|
10
|
+
- Unit test files are co-located with the code they test
|
|
11
|
+
- Use `.spec.ts` extension for test files
|
|
12
|
+
- Example: `my-component.ts` → `my-component.spec.ts`
|
|
13
|
+
|
|
14
|
+
## Basic Test Structure
|
|
15
|
+
```typescript
|
|
16
|
+
describe('ComponentName', () => {
|
|
17
|
+
let component: ComponentName;
|
|
18
|
+
let fixture: ComponentFixture<ComponentName>;
|
|
19
|
+
|
|
20
|
+
beforeEach(async () => {
|
|
21
|
+
await TestBed.configureTestingModule({
|
|
22
|
+
imports: [ComponentName],
|
|
23
|
+
providers: [/* services */]
|
|
24
|
+
}).compileComponents();
|
|
25
|
+
fixture = TestBed.createComponent(ComponentName);
|
|
26
|
+
component = fixture.componentInstance;
|
|
27
|
+
});
|
|
28
|
+
|
|
29
|
+
test('should do something specific', () => {
|
|
30
|
+
fixture.detectChanges();
|
|
31
|
+
expect(actual).toBe(expected);
|
|
32
|
+
});
|
|
33
|
+
});
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
**Key points:**
|
|
37
|
+
- Always use `async` on `beforeEach` and `await` + `.compileComponents()` on `configureTestingModule()` to properly compile components
|
|
38
|
+
- Always call `fixture.detectChanges()` before asserting anything about the component (triggers Angular initialization and change detection)
|
|
39
|
+
|
|
40
|
+
## Angular Testing
|
|
41
|
+
- Test component behavior, not implementation details
|
|
42
|
+
- Test DOM interactions through the fixture using `fixture.detectChanges()`
|
|
43
|
+
- For async operations: use `fixture.whenStable()` to wait for pending async tasks or `async`/`waitForAsync` and `fakeAsync`
|
|
44
|
+
|
|
45
|
+
## Best Practices
|
|
46
|
+
- **Descriptive test names**: Use "should..." pattern in it() names
|
|
47
|
+
- **Be concise**: Keep tests to as few lines as possible. Avoid unnecessary variable declarations. Use helper functions for common test data.
|
|
48
|
+
- **Structure tests logically**: Group related tests using nested `describe` blocks
|
|
49
|
+
- **Mock external dependencies**: Don't test third-party code
|
|
50
|
+
- **Test user behavior**: Focus on what users experience, not implementation details
|
|
51
|
+
- **Avoid arbitrary sleeps**: Do NOT use `setTimeout` in tests — instead use `fixture.whenStable()` or `await` for async operations
|
|
52
|
+
- **Don't duplicate**: Use `beforeEach` for common setup, or extract helper functions
|
|
53
|
+
- **Avoid brittleness**: Don't depend on exact backend data structure details that may change
|
|
54
|
+
- **Always call `detectChanges()` before assertions**: Angular change detection must run before testing component state or DOM
|
|
55
|
+
- **Mock comprehensively**: If a service has 10 public methods and your component calls 8 of them, mock all 8 in the test setup to avoid runtime errors later
|
|
56
|
+
|
|
57
|
+
## Common Pitfalls to Avoid
|
|
58
|
+
- ❌ **Forgetting `async` and `.compileComponents()`**: `beforeEach(() => { ... })` without `async`/`await` leaves components uncompiled
|
|
59
|
+
- ❌ **Missing `fixture.detectChanges()`**: Component won't initialize without this; properties will be undefined
|
|
60
|
+
- ❌ **Incomplete service mocks**: Mocking only some methods causes "is not a function" errors on unmocked methods
|
|
61
|
+
- ❌ **Wrong mock return types**: Returning `[]` when the method returns `{ data: [], paging: {} }` causes destructuring errors
|
|
62
|
+
- ❌ **Not providing all dependencies**: Missing providers (e.g., `TranslateService`) causes "No provider found" errors
|
|
63
|
+
- ✅ **DO**: Mock all methods, use correct async patterns, always call `detectChanges()`, verify return types match the real service
|
|
64
|
+
|
|
65
|
+
## Common Test Patterns
|
|
66
|
+
```typescript
|
|
67
|
+
// Testing component initialization
|
|
68
|
+
it('should initialize with default values', () => {
|
|
69
|
+
fixture.detectChanges();
|
|
70
|
+
expect(component.propertyName).toBe(expectedValue);
|
|
71
|
+
});
|
|
72
|
+
|
|
73
|
+
// Testing async operations
|
|
74
|
+
it('should load data on init', async () => {
|
|
75
|
+
fixture.detectChanges();
|
|
76
|
+
await fixture.whenStable();
|
|
77
|
+
fixture.detectChanges();
|
|
78
|
+
expect(component.data).toBeDefined();
|
|
79
|
+
});
|
|
80
|
+
|
|
81
|
+
// Testing user interactions
|
|
82
|
+
it('should emit event when button clicked', () => {
|
|
83
|
+
fixture.detectChanges();
|
|
84
|
+
jest.spyOn(component.outputEvent, 'emit');
|
|
85
|
+
fixture.nativeElement.querySelector('button').click();
|
|
86
|
+
expect(component.outputEvent.emit).toHaveBeenCalled();
|
|
87
|
+
});
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
## TypeScript in Tests
|
|
91
|
+
- Use proper types, avoid `any`
|
|
92
|
+
- Type your test data and mocks
|
|
93
|
+
- Use interfaces from the application code
|
|
94
|
+
- Enable strict mode for better type safety
|
|
95
|
+
|
|
96
|
+
# Setup & Mocking
|
|
97
|
+
|
|
98
|
+
## Mocking
|
|
99
|
+
|
|
100
|
+
### TestBed Setup with jest.fn()
|
|
101
|
+
|
|
102
|
+
Use **TestBed.configureTestingModule** for component setup and **jest.fn()** for mock service objects:
|
|
103
|
+
|
|
104
|
+
```typescript
|
|
105
|
+
beforeEach(async () => {
|
|
106
|
+
await TestBed.configureTestingModule({
|
|
107
|
+
imports: [MyComponent],
|
|
108
|
+
providers: [
|
|
109
|
+
{
|
|
110
|
+
provide: MyService,
|
|
111
|
+
useValue: {
|
|
112
|
+
getData: jest.fn().mockResolvedValue(data),
|
|
113
|
+
logout: jest.fn()
|
|
114
|
+
}
|
|
115
|
+
}
|
|
116
|
+
]
|
|
117
|
+
}).compileComponents();
|
|
118
|
+
fixture = TestBed.createComponent(MyComponent);
|
|
119
|
+
component = fixture.componentInstance;
|
|
120
|
+
});
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
**Important mocking guidelines:**
|
|
124
|
+
- **Mock all public methods** that the component or its children might call, not just a few
|
|
125
|
+
- **Match return types exactly**: If a method returns `Promise<T>`, use `.mockResolvedValue(T)`; if it returns an object with properties, return a properly structured object (e.g., `{ data: [], paging: {} }`)
|
|
126
|
+
- **Use `.mockResolvedValue()` for async methods** to return promises correctly
|
|
127
|
+
- **Use `.mockReturnValue()` for synchronous methods**
|
|
128
|
+
- **Type your mocks** to catch missing methods early: `useValue: {...} as jest.Mocked<MyService>`
|
|
129
|
+
|
|
130
|
+
### Spying on Component/Service Methods
|
|
131
|
+
|
|
132
|
+
```typescript
|
|
133
|
+
const service = TestBed.inject(MyService);
|
|
134
|
+
jest.spyOn(service, 'getData').mockReturnValue(value);
|
|
135
|
+
|
|
136
|
+
// Or for component methods:
|
|
137
|
+
jest.spyOn(component, 'onSubmit');
|
|
138
|
+
component.handleForm();
|
|
139
|
+
expect(component.onSubmit).toHaveBeenCalled();
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
## Matchers
|
|
143
|
+
- `toBe()` - Strict equality (===)
|
|
144
|
+
- `toEqual()` - Deep equality
|
|
145
|
+
- `toBeTruthy()` / `toBeFalsy()`
|
|
146
|
+
- `toContain()` - Array/string contains
|
|
147
|
+
- `toHaveBeenCalled()` - Spy was called
|
|
148
|
+
- `toHaveBeenCalledWith(args)` - Spy called with specific arguments
|
|
149
|
+
- `toHaveLength(n)` - Array/string length
|
|
150
|
+
- `toThrow()` / `toThrowError()` - Exception testing
|
|
151
|
+
- See [Jest matchers documentation](https://jestjs.io/docs/expect) for complete list
|
|
152
|
+
|
|
153
|
+
## Running Tests
|
|
154
|
+
- Run specific file: `yarn jest my-component.spec.ts`
|
|
155
|
+
- Run with watch mode: `yarn jest --watch my-component.spec.ts`
|
|
156
|
+
- Run single test suite: `yarn jest my-component.spec.ts -t '^SuiteName(\\s.*)?$'`
|
|
157
|
+
- Debug race conditions: `yarn jest my-component.spec.ts --testNamePattern="Test Name" --maxWorkers=1`
|
|
158
|
+
|
|
159
|
+
## Coverage
|
|
160
|
+
- Aim for high coverage but focus on meaningful tests
|
|
161
|
+
- Ensure exception cases are covered where possible
|
|
162
|
+
- Focus on critical paths and edge cases
|
|
163
|
+
|
|
164
|
+
## Resources
|
|
165
|
+
- Jest documentation: https://jestjs.io/
|
|
166
|
+
- Angular testing guide: https://angular.dev/guide/testing
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
## Project Identity
|
|
2
|
+
|
|
3
|
+
**Cumulocity IoT Web Application** — custom web frontend built with the Cumulocity Web SDK. Extends the Cumulocity IoT platform with custom features and integrations.
|
|
4
|
+
|
|
5
|
+
- **Stack:** Angular 20, TypeScript 5.9.3, RxJS 7.8, Jest 30, Cypress 15, ESLint (airbnb-base + angular-eslint)
|
|
6
|
+
- **Core Libraries:** `@c8y/ngx-components`, `@c8y/client`, `@c8y/toolkit`, `@c8y/devkit`, `@c8y/bootstrap`
|
|
7
|
+
- **Structure:** Standard Angular CLI application scaffolded with `ng add @c8y/websdk`
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 🛑 MANDATORY WORKFLOW: UI Planning & Implementation
|
|
12
|
+
|
|
13
|
+
**STOP: Before analyzing, planning, designing, OR implementing ANY UI feature/component, you MUST complete this workflow. No exceptions.**
|
|
14
|
+
|
|
15
|
+
### Step 1: Fetch Codex Documentation (REQUIRED BEFORE PLANNING)
|
|
16
|
+
|
|
17
|
+
When the user requests ANY UI work (planning, design, implementation), your **FIRST ACTION** must be:
|
|
18
|
+
|
|
19
|
+
1. **Fetch** https://cumulocity.com/codex/llms.txt
|
|
20
|
+
2. **Search** the content for relevant component keywords (modal, button, form, table, etc.)
|
|
21
|
+
3. **If found:** Read the specific `.md` documentation file like `https://cumulocity.com/codex/components/forms/editor.md`
|
|
22
|
+
4. **Read and analyze** the documentation content
|
|
23
|
+
5. **Locate examples** in the public tutorial repository:
|
|
24
|
+
e.g. for file path './packages/tutorial/src/selector/asset-selector-example/tree-options/asset-selector-tree-example.component.ts' get file from
|
|
25
|
+
'https://github.com/Cumulocity-IoT/tutorial/tree/main/src/selector/asset-selector-example/tree-options/asset-selector-tree-example.component.ts'
|
|
26
|
+
6. **Read example code** to understand the official pattern
|
|
27
|
+
|
|
28
|
+
**⛔ INVALID:**
|
|
29
|
+
- ❌ "I'll list the Codex URL as a resource to review later"
|
|
30
|
+
- ❌ "The plan should include fetching the documentation"
|
|
31
|
+
- ❌ "Before implementation, we need to review the Codex"
|
|
32
|
+
- ❌ Making a plan without actually fetching and reading documentation
|
|
33
|
+
|
|
34
|
+
**✅ VALID:**
|
|
35
|
+
- ✓ Fetch llms.txt → Find modal docs → Read content → Find tutorial examples → Read example code → Then create plan
|
|
36
|
+
|
|
37
|
+
### Step 2: Check for Existing Components
|
|
38
|
+
|
|
39
|
+
After reviewing documentation:
|
|
40
|
+
|
|
41
|
+
1. Search `@c8y/ngx-components` for existing implementations
|
|
42
|
+
2. Use a matching Cumulocity component if one exists — **never build custom equivalents**
|
|
43
|
+
3. Only proceed with custom solution if nothing suitable exists
|
|
44
|
+
|
|
45
|
+
### Step 3: Plan or Implement
|
|
46
|
+
|
|
47
|
+
Only after completing Steps 1-2, proceed with planning or implementation.
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## Universal Rules — TypeScript
|
|
52
|
+
|
|
53
|
+
- Target is ES2022; do not use syntax unavailable in ES2022
|
|
54
|
+
- Enable strict mode where possible; use explicit types or `unknown` with narrowing guards
|
|
55
|
+
- Avoid `any`; prefer explicit types
|
|
56
|
+
- Use path aliases for imports: `@c8y/ngx-components`, `@c8y/client`, `@c8y/devkit`, `@c8y/options`
|
|
57
|
+
- `experimentalDecorators: true` is set globally; Angular decorator syntax is valid as-is
|
|
58
|
+
|
|
59
|
+
## Universal Rules — Cumulocity Platform
|
|
60
|
+
|
|
61
|
+
### Other rules
|
|
62
|
+
|
|
63
|
+
- Use `@c8y/client` services for all Cumulocity REST calls — do **not** use `HttpClient` directly for platform endpoints
|
|
64
|
+
- Check `@c8y/ngx-components` before building custom UI components — it exports a large shared library. Search by visual functionality in [Codex](https://cumulocity.com/codex)
|
|
65
|
+
- Wrap every user-facing string with `C8yTranslatePipe` (`| translate`) or `TranslateService`:
|
|
66
|
+
- ✅ `{{ 'Save' | translate }}` ❌ `Save`
|
|
67
|
+
|
|
68
|
+
## Angular Patterns
|
|
69
|
+
|
|
70
|
+
- All new components must be **standalone** (`standalone: true`) — do not create NgModule-based components
|
|
71
|
+
- Prefer `ChangeDetectionStrategy.OnPush` for new components (no project-wide enforcement, but scale demands it)
|
|
72
|
+
- Constructor injection and `inject()` function are both present; either is acceptable
|
|
73
|
+
- Manage subscriptions with `async` pipe or `takeUntilDestroyed()` — avoid bare `unsubscribe()` without `ngOnDestroy`
|
|
74
|
+
- Use signals for local component state
|
|
75
|
+
- Consider extracting child components when template exceeds ~150 lines or class exceeds ~200 lines
|
|
76
|
+
|
|
77
|
+
## Code Quality (PR Review Focus)
|
|
78
|
+
|
|
79
|
+
- Remove `console.log` / `console.debug` before commit; `console.error` acceptable in caught exceptions
|
|
80
|
+
- Flag methods exceeding ~40 lines — consider decomposition
|
|
81
|
+
- Remove commented-out code; use git history for recovery
|
|
82
|
+
- New features should have `*.spec.ts` unit tests; new user flows should have Cypress coverage
|
|
83
|
+
- Document types, methods and properties that are not self-explanatory; don't explain ones that are obvious
|
|
84
|
+
- Test use cases that are truly worth testing, do not create test cases just for the sake of tests volume or coverate
|
|
85
|
+
|
|
86
|
+
## Security Checks
|
|
87
|
+
|
|
88
|
+
- Flag hardcoded tenant IDs, device IDs, credentials, or API tokens — use `Cypress.env()` in tests, env config in production
|
|
89
|
+
- Review components rendering dynamic device/asset data for XSS: prefer `{{ }}` over `[innerHTML]` with unescaped values
|
|
90
|
+
- Treat IoT payload data as untrusted — validate and sanitize before display
|
|
91
|
+
- Do not expose internal hostnames or credentials in client-side code
|
|
92
|
+
|
|
93
|
+
## What NOT to Flag
|
|
94
|
+
|
|
95
|
+
- **Import order** — managed by ESLint
|
|
96
|
+
- **Quote style / semicolons** — ESLint enforces single quotes and required semicolons
|
|
97
|
+
- **Trailing commas on function parameters** — ESLint explicitly disallows them
|
|
98
|
+
- **`skipLibCheck: true`** in tsconfig — intentional project setting
|