tests/performance/utils/config.js (3)

35-40: Hardcoded test credentials pose a security risk.

Test credentials are hardcoded in source code, which is a security vulnerability. Consider using environment variables or a secure configuration file.

---

47-47: Use Date.now() for better performance.

Date.now() is more efficient than new Date().getTime() for getting timestamps.

---

50-53: Add validation for min/max parameters.

The function doesn't validate that min is less than max, which could lead to unexpected behavior.

tests/performance/utils/helpers.js (2)

10-12: Specify timeout for HTTP requests.

HTTP requests should have explicit timeout configurations to prevent hanging requests during performance testing.

---

16-16: Avoid brittle DOM element checks.

The test relies on a specific DOM element (data-testid="day"), making it fragile to UI changes. Consider checking for more stable indicators of successful page load.

tests/performance/spike/booking.js (2)

7-12: Spike test ramp-up pattern may be too aggressive for realistic simulation.

The current spike test rapidly increases from 500 to 5000 VUs in just 2 minutes, which may not accurately represent real-world traffic spike patterns and could overwhelm the system too quickly to gather meaningful performance data.

---

23-23: Sleep duration is too short for realistic load simulation.

The 0.01 second sleep time may not provide sufficient pause between iterations, potentially causing excessive load beyond what's intended and not reflecting realistic user behavior patterns.

tests/performance/load/booking.js (1)

23-23: Consider increasing sleep duration for more realistic load simulation.

The 0.1 second sleep might be too aggressive and not representative of real user behavior. Consider increasing to 0.5-1 second for more realistic think time.

-  sleep(0.1);
+  sleep(0.5);

tests/performance/README.md (1)

62-62: Consider expanding the test scenarios section.

The documentation mentions that the test suite "focuses specifically on the booking flow" but only describes one scenario. Consider adding more details about what aspects of the booking flow are being tested or potential future scenarios.

tests/performance/stress/booking.js (1)

25-25: Consider making sleep duration configurable.

The sleep duration could be made configurable through the shared config to maintain consistency across different test types and allow for easy adjustment.

You could add a sleep configuration to utils/config.js:

export const SLEEP_DURATION = {
  SMOKE: 0.1,
  LOAD: 0.08,
  STRESS: 0.05,
  SPIKE: 0.01,
};

Then import and use it in the test:

+import { THRESHOLDS, SLEEP_DURATION } from "../utils/config.js";
-  sleep(0.05);
+  sleep(SLEEP_DURATION.STRESS);

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

tests/performance/utils/config.js (2)

38-43: Placeholders for credentials are acceptable; avoid real secrets.

Defaults use "free"/"pro" placeholders. Keep it that way and ensure no real credentials are committed.

---

49-51: Good choice using Date.now() for lightweight cache-busting.

Efficient and entirely sufficient for this use case.

tests/performance/README.md (1)

78-86: Add a language to the fenced code block to satisfy markdownlint (MD040).

The interactive menu code block is missing a language identifier.

Apply this diff:

-```
+```text
 Select a test:
   1) smoke
   2) load
   3) stress
   4) spike
   5) all
   0) exit

</blockquote></details>
<details>
<summary>tests/scripts/run-k6-local.sh (2)</summary><blockquote>

`28-30`: **Pass through K6_CLOUD_TOKEN to support cloud runs.**

Forwarding K6_CLOUD_TOKEN makes the same script usable with k6 cloud without local tweaks.



Apply this diff:

```diff
-for v in TOKEN TEST_USER_FREE TEST_PASSWORD_FREE TEST_USER_PRO TEST_PASSWORD_PRO; do
+for v in TOKEN TEST_USER_FREE TEST_PASSWORD_FREE TEST_USER_PRO TEST_PASSWORD_PRO K6_CLOUD_TOKEN; do
   if [ -n "${!v:-}" ]; then ENV_ARGS+=(-e "$v=${!v}"); fi
 done

---

14-15: Consider pinning the k6 Docker image for reproducibility.

Using an unpinned image tag can yield different results over time. Prefer a fixed version (override-able) to keep test results consistent across runs.

Example (no need to use this exact version; pick the one you standardize on):

-K6_IMAGE="${K6_IMAGE:-grafana/k6}"
+K6_IMAGE="${K6_IMAGE:-grafana/k6:0.49.0}"

Alternatively, keep current default and document that CI/local users should set K6_IMAGE to a pinned tag.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: CR
PR: calcom/cal.com#0
File: .cursor/rules/review.mdc:0-0
Timestamp: 2025-07-28T11:50:23.946Z
Learning: Applies to **/*.{ts,tsx} : Flag excessive Day.js use in performance-critical code; prefer native Date or Day.js `.utc()` in hot paths like loops

Learnt from: vijayraghav-io
PR: calcom/cal.com#21072
File: .env.example:354-357
Timestamp: 2025-07-18T08:49:18.779Z
Learning: For E2E integration tests that require real third-party service credentials (like Outlook calendar), it's acceptable to temporarily include actual test account credentials in .env.example during feature development and validation, provided there's a clear plan to replace them with placeholder values before final release. Test credentials should be for dedicated test tenants/accounts, not production systems.