Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Extract the monitoring concerns out of `src/monitoring/monitoring.spec.ts` (529 lines)

Open
  • Is something wrong?
#201 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
nodejs, typescript
Domain
observability, testing

Research direction

Start by reading src/monitoring/monitoring.spec.ts to see which describe blocks map to which service, and note the shared fixtures and mock setup at its top. The services to cover are in src/monitoring/, including metrics-history.service.ts, whose cap and trim logic (lines 55-56, 97-109, 122-123) needs explicit tests. Done means one colocated spec per service, the shared setup moved into a helper, and the same number of assertions before and after, with npm test passing.

Written by the indexing model from the issue text.

Description

intermediate refactor tests

Problem

src/monitoring/monitoring.spec.ts is 529 lines — the sixth-largest file in src/, and larger than several of the services it is meant to test. Compare src/rate-limiting/rate-limiter.service.spec.ts at 450 lines for a single service.

The file appears to cover all of src/monitoring/ at once:

  • src/monitoring/system-metrics.service.ts
  • src/monitoring/monitoring-metrics.service.ts
  • src/monitoring/metrics-history.service.ts
  • src/monitoring/alert-rules.service.ts
  • src/monitoring/monitoring.controller.ts

None of these has a colocated spec; this one file is the entire test coverage for the module.

Why it matters

A single monolithic spec is hard to run in isolation, hard to extend, and its failure output does not say which concern broke. It also discourages the colocated convention used elsewhere in src/ (97 colocated *.spec.ts files exist, so the convention is established — this file just does not follow it). When someone adds a feature to alert-rules.service.ts, they will either append to this 529-line file or start a new one, and neither is a good outcome.

Suggested Direction

Split into colocated specs, one per service, following the dominant convention:

src/monitoring/metrics-history.service.spec.ts
src/monitoring/alert-rules.service.spec.ts
src/monitoring/system-metrics.service.spec.ts
src/monitoring/monitoring-metrics.service.spec.ts
src/monitoring/monitoring.controller.spec.ts

metrics-history.service.ts deserves its own file in particular — it has genuinely testable logic worth pinning down: the MONITORING_HISTORY_MAX_POINTS cap (lines 55-56, default 5760), the points.push / slice trim at lines 97-109, and the limit filter at lines 122-123. Bounded-memory behaviour is exactly the kind of thing that regresses silently.

Reuse whatever shared fixtures and mock setup exist at the top of the current file by extracting them into a small helper under src/monitoring/ rather than copy-pasting.

Constraints

  • Pure restructure — no behaviour changes. Every existing assertion must survive the split.
  • jest.config.js has rootDir: 'src' and testRegex: '.*\.spec\.ts$', so colocated files are discovered automatically. No config change needed.
  • Confirm the total assertion count is unchanged before and after, so nothing is quietly dropped.

Acceptance Criteria

  • src/monitoring/monitoring.spec.ts is split into per-service colocated specs.
  • metrics-history.service.spec.ts covers the maxPoints cap and trim behaviour explicitly.
  • The total number of assertions is unchanged from before the split.
  • npm test passes and src/monitoring/monitoring.spec.ts no longer exists as a monolith.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.