Skip to content

🧪 [testing improvement] Add unit tests for buildEventSeries#185

Open
is0692vs wants to merge 3 commits intomainfrom
jules-12395233438043416379-eee27882
Open

🧪 [testing improvement] Add unit tests for buildEventSeries#185
is0692vs wants to merge 3 commits intomainfrom
jules-12395233438043416379-eee27882

Conversation

@is0692vs
Copy link
Copy Markdown
Contributor

@is0692vs is0692vs commented Apr 18, 2026

🎯 What: The testing gap addressed: The buildEventSeries function was previously missing from test coverage metrics because its file was omitted from the vitest.config.ts configuration, causing tests to be ignored by Codecov. Furthermore, adding explicit tests for how the utility maps specific properties was necessary.

📊 Coverage: What scenarios are now tested:

  • Added vitest.config.ts configurations to include src/components/DashboardStatsClient.tsx.
  • Explicitly tested the current implementation's property mapping behavior to document expected inputs vs outputs (how type maps to name and count).

Result: The improvement in test coverage: Coverage tracking for the previously unmonitored src/components/DashboardStatsClient.tsx is now enabled, accurately reflecting the suite's state, and specific behavior edge-cases have been documented via explicit vitest assertions.


PR created automatically by Jules for task 12395233438043416379 started by @is0692vs

Greptile Summary

このPRは buildEventSeries のユニットテストを追加し、vitest.config.ts のカバレッジ対象に DashboardStatsClient.tsx を加えることでコードカバレッジの計測漏れを修正します。既存テストの網羅性は十分ですが、今回追加されたテストケースが既存テストと重複している点と、ファイル内の未テスト関数によるカバレッジ閾値違反リスクについて確認が必要です。

Confidence Score: 5/5

P2指摘のみのため、マージ自体は安全です。

全ての指摘がP2(テスト名の誤記・重複、カバレッジ閾値の潜在的リスク)であり、実装ロジックに欠陥はありません。カバレッジ閾値違反もローカル確認で回避できる範囲です。

vitest.config.ts — カバレッジ閾値への影響を事前検証することを推奨

Important Files Changed

Filename Overview
src/components/tests/DashboardStatsClient.test.ts 既存テストと重複するテストケースを1件追加。テスト名に誤った用語("value")が含まれており、誤解を招く。
vitest.config.ts カバレッジ対象に DashboardStatsClient.tsx を追加。ファイル内の未テスト関数(4/5)により集計カバレッジが閾値を下回るリスクがある。

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[vitest run --coverage] --> B{coverage include}
    B --> C[src/lib/**/*.ts]
    B --> D[src/hooks/**/*.ts]
    B --> E[src/components/DashboardStatsClient.tsx ✨ NEW]

    E --> F[buildEventSeries\n✅ テスト済み]
    E --> G[StatBarChart\n❌ 未テスト]
    E --> H[EventBreakdownChart\n❌ 未テスト]
    E --> I[MonthlyContributionsChart\n❌ 未テスト]
    E --> J[DashboardStatsClient default\n❌ 未テスト]

    F --> K[関数カバレッジ: 1/5 = 20%]
    G --> K
    H --> K
    I --> K
    J --> K

    K --> L{閾値チェック\nfunctions: 80%}
    L -- 集計で80%以上 --> M[✅ CI通過]
    L -- 集計で80%未満 --> N[❌ CI失敗リスク]
Loading
Prompt To Fix All With AI
This is a comment left during a code review.
Path: src/components/__tests__/DashboardStatsClient.test.ts
Line: 58-65

Comment:
**テスト名が誤解を招く + 既存テストと重複**

テスト名に `"mapping to value"` という表現が含まれていますが、`buildEventSeries` が返すプロパティは `value` ではなく `count` です。また、このテストの入力 `{ type: "PushEvent", count: 10 }` と期待値 `name: 'Push'`, `count: 10` は、既存の `"should replace 'Event' with an empty string in the name property"` テスト(12行目)で既に完全に網羅されており、実質的に重複しています。

テスト名を修正するか、新たに「`Event` が含まれない型でも `Event` 除去が安全に行われる」や「上限6件の境界値」など既存でカバーされていない挙動を検証するテストに置き換えることを推奨します。

```suggestion
  it("should map e.type to name and e.count to count", () => {
    const input = [{ type: "PushEvent", count: 10 }];
    const result = buildEventSeries(input);
    expect(result[0]).toHaveProperty('name', 'Push');
    expect(result[0]).toHaveProperty('count', 10);
  });
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: vitest.config.ts
Line: 14

Comment:
**カバレッジ閾値違反のリスク**

`DashboardStatsClient.tsx` にはテスト対象の `buildEventSeries` のほかに、`StatBarChart``EventBreakdownChart``MonthlyContributionsChart``DashboardStatsClient`(デフォルトエクスポート)の計4つの関数が定義されています。現行テストはこれらをまったく呼び出しておらず、ファイル単体の関数カバレッジは約 20%(1/5)になります。集計カバレッジが既存ファイル群で余裕をもって 80% を超えていれば問題ありませんが、ボーダーライン付近の場合はこの追加で `functions: 80` 閾値を下回り CI が失敗するリスクがあります。事前にローカルで `vitest run --coverage` を実行して閾値違反が起きないことを確認することを推奨します。

How can I resolve this? If you propose a fix, please make it concise.

Reviews (1): Last reviewed commit: "🧪 [testing improvement] Add unit tests ..." | Re-trigger Greptile

Greptile also left 2 inline comments on this PR.

Co-authored-by: is0692vs <135803462+is0692vs@users.noreply.github.com>
@google-labs-jules
Copy link
Copy Markdown
Contributor

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@vercel
Copy link
Copy Markdown

vercel bot commented Apr 18, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
github-user-summary Ready Ready Preview, Comment Apr 18, 2026 3:37am

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 18, 2026

Warning

Rate limit exceeded

@is0692vs has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 56 minutes and 16 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 56 minutes and 16 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: ee60ded9-f508-4de6-b4a6-9973f615918f

📥 Commits

Reviewing files that changed from the base of the PR and between 360cec8 and ec504d7.

📒 Files selected for processing (3)
  • src/components/__tests__/DashboardStatsClient.test.ts
  • src/components/__tests__/DashboardStatsClient.test.tsx
  • vitest.config.ts
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch jules-12395233438043416379-eee27882

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds a new test case for the buildEventSeries function and updates the Vitest configuration to include a specific component in code coverage reports. Feedback suggests removing the new test case because it is redundant and contains an inconsistent description relative to its assertions. Additionally, it is recommended to use a glob pattern in the coverage configuration to automatically include all components rather than listing them individually.

Comment on lines +58 to +65
it("should return an array mapping e.type to name and e.count to value if mapping to value is expected", () => {
// Testing the current behavior of the function, which actually maps to count,
// replacing Event in the name string based on the source code structure.
const input = [{ type: "PushEvent", count: 10 }];
const result = buildEventSeries(input);
expect(result[0]).toHaveProperty('name', 'Push');
expect(result[0]).toHaveProperty('count', 10);
});
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This test case is redundant as the logic for mapping type to name and verifying the count property is already covered by existing tests (see lines 9-21 and 40-50). Furthermore, the test description mentions mapping to a value property, which is inconsistent with the code that asserts against the count property. Removing this redundant test will improve the maintainability of the test suite.

Comment thread vitest.config.ts
provider: "v8",
reporter: ["text", "lcov"],
include: ["src/lib/**/*.ts", "src/hooks/**/*.ts"],
include: ["src/lib/**/*.ts", "src/hooks/**/*.ts", "src/components/DashboardStatsClient.tsx"],
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Instead of adding individual component files to the coverage include list, it is more robust to use a glob pattern. This ensures that all current and future components in the src/components directory are automatically tracked for coverage.

Suggested change
include: ["src/lib/**/*.ts", "src/hooks/**/*.ts", "src/components/DashboardStatsClient.tsx"],
include: ["src/lib/**/*.ts", "src/hooks/**/*.ts", "src/components/**/*.{ts,tsx}"],

Comment on lines +58 to +65
it("should return an array mapping e.type to name and e.count to value if mapping to value is expected", () => {
// Testing the current behavior of the function, which actually maps to count,
// replacing Event in the name string based on the source code structure.
const input = [{ type: "PushEvent", count: 10 }];
const result = buildEventSeries(input);
expect(result[0]).toHaveProperty('name', 'Push');
expect(result[0]).toHaveProperty('count', 10);
});
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 テスト名が誤解を招く + 既存テストと重複

テスト名に "mapping to value" という表現が含まれていますが、buildEventSeries が返すプロパティは value ではなく count です。また、このテストの入力 { type: "PushEvent", count: 10 } と期待値 name: 'Push', count: 10 は、既存の "should replace 'Event' with an empty string in the name property" テスト(12行目)で既に完全に網羅されており、実質的に重複しています。

テスト名を修正するか、新たに「Event が含まれない型でも Event 除去が安全に行われる」や「上限6件の境界値」など既存でカバーされていない挙動を検証するテストに置き換えることを推奨します。

Suggested change
it("should return an array mapping e.type to name and e.count to value if mapping to value is expected", () => {
// Testing the current behavior of the function, which actually maps to count,
// replacing Event in the name string based on the source code structure.
const input = [{ type: "PushEvent", count: 10 }];
const result = buildEventSeries(input);
expect(result[0]).toHaveProperty('name', 'Push');
expect(result[0]).toHaveProperty('count', 10);
});
it("should map e.type to name and e.count to count", () => {
const input = [{ type: "PushEvent", count: 10 }];
const result = buildEventSeries(input);
expect(result[0]).toHaveProperty('name', 'Push');
expect(result[0]).toHaveProperty('count', 10);
});
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/components/__tests__/DashboardStatsClient.test.ts
Line: 58-65

Comment:
**テスト名が誤解を招く + 既存テストと重複**

テスト名に `"mapping to value"` という表現が含まれていますが、`buildEventSeries` が返すプロパティは `value` ではなく `count` です。また、このテストの入力 `{ type: "PushEvent", count: 10 }` と期待値 `name: 'Push'`, `count: 10` は、既存の `"should replace 'Event' with an empty string in the name property"` テスト(12行目)で既に完全に網羅されており、実質的に重複しています。

テスト名を修正するか、新たに「`Event` が含まれない型でも `Event` 除去が安全に行われる」や「上限6件の境界値」など既存でカバーされていない挙動を検証するテストに置き換えることを推奨します。

```suggestion
  it("should map e.type to name and e.count to count", () => {
    const input = [{ type: "PushEvent", count: 10 }];
    const result = buildEventSeries(input);
    expect(result[0]).toHaveProperty('name', 'Push');
    expect(result[0]).toHaveProperty('count', 10);
  });
```

How can I resolve this? If you propose a fix, please make it concise.

Comment thread vitest.config.ts
provider: "v8",
reporter: ["text", "lcov"],
include: ["src/lib/**/*.ts", "src/hooks/**/*.ts"],
include: ["src/lib/**/*.ts", "src/hooks/**/*.ts", "src/components/DashboardStatsClient.tsx"],
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 カバレッジ閾値違反のリスク

DashboardStatsClient.tsx にはテスト対象の buildEventSeries のほかに、StatBarChartEventBreakdownChartMonthlyContributionsChartDashboardStatsClient(デフォルトエクスポート)の計4つの関数が定義されています。現行テストはこれらをまったく呼び出しておらず、ファイル単体の関数カバレッジは約 20%(1/5)になります。集計カバレッジが既存ファイル群で余裕をもって 80% を超えていれば問題ありませんが、ボーダーライン付近の場合はこの追加で functions: 80 閾値を下回り CI が失敗するリスクがあります。事前にローカルで vitest run --coverage を実行して閾値違反が起きないことを確認することを推奨します。

Prompt To Fix With AI
This is a comment left during a code review.
Path: vitest.config.ts
Line: 14

Comment:
**カバレッジ閾値違反のリスク**

`DashboardStatsClient.tsx` にはテスト対象の `buildEventSeries` のほかに、`StatBarChart``EventBreakdownChart``MonthlyContributionsChart``DashboardStatsClient`(デフォルトエクスポート)の計4つの関数が定義されています。現行テストはこれらをまったく呼び出しておらず、ファイル単体の関数カバレッジは約 20%(1/5)になります。集計カバレッジが既存ファイル群で余裕をもって 80% を超えていれば問題ありませんが、ボーダーライン付近の場合はこの追加で `functions: 80` 閾値を下回り CI が失敗するリスクがあります。事前にローカルで `vitest run --coverage` を実行して閾値違反が起きないことを確認することを推奨します。

How can I resolve this? If you propose a fix, please make it concise.

Co-authored-by: is0692vs <135803462+is0692vs@users.noreply.github.com>
@codecov
Copy link
Copy Markdown

codecov bot commented Apr 18, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Co-authored-by: is0692vs <135803462+is0692vs@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant