Add initial performance tests for BitActionButton (#11927)

[msynk]

closes #11927

Summary by CodeRabbit

Tests

• Added comprehensive performance testing suite for the BitActionButton component, measuring memory footprint, render speeds, scalability, and behavior under stress scenarios across varying component configurations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

A comprehensive performance testing suite for BitActionButton is introduced, containing 15+ test methods organized across five test regions: Memory Footprint, Initial Render Speed, Re-render Speed, Scalability, and Stress Tests. Tests measure performance metrics with parameterized component counts and configurable thresholds.

Changes

Cohort / File(s)

Summary

New Performance Test Suite src/BlazorUI/Bit.BlazorUI.Tests/Components/Buttons/BitActionButtonPerformanceTests.cs

Adds BitActionButtonPerformanceTests class with 15 test methods across five regions: memory footprint (simple, features, link), initial render speed (simple, features, loading), re-render speed (parameter/icon/loading/content/multi-parameter changes), scalability (render time and memory growth), and stress tests (rapid re-renders, many components, alternating states). Includes helper methods for garbage collection and performance threshold assertion (overloaded for double and long types).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 A suite of tests hops through the day,
Measuring speed in every way,
Memory, renders, stress and scale,
ButtonActionBits will never fail! 🎯✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 10.53% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the primary change: adding initial performance tests for BitActionButton, which is the main objective.
Linked Issues check	✅ Passed	The pull request fully addresses the linked issue #11927 by implementing comprehensive performance tests for BitActionButton.
Out of Scope Changes check	✅ Passed	All changes are within scope—only performance test additions for BitActionButton with no unrelated modifications.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (5)

src/BlazorUI/Bit.BlazorUI.Tests/Components/Buttons/BitActionButtonPerformanceTests.cs (5)

20-29: Consider aligning ComponentCounts with DataRow values to avoid maintenance burden.

The ComponentCounts array includes 500, but the DataRow-parameterized tests only use [1, 10, 50, 100]. This inconsistency could lead to confusion and maintenance issues. Consider either:

1. Using ComponentCounts values to generate DataRow attributes dynamically (not directly supported in MSTest), or
2. Adding [DataRow(500)] to relevant tests, or
3. Documenting why the scalability tests include 500 but other tests don't.

---

51-53: GC measurement inconsistency may affect accuracy.

Line 34 uses forceFullCollection: true, but line 51 uses forceFullCollection: false. For more consistent and accurate memory measurements, consider using the same setting for both calls. Using false after the measurement may leave unreferenced objects uncollected, potentially affecting the delta calculation.

🔎 Suggested fix

-        var memoryAfter = GC.GetTotalMemory(forceFullCollection: false);
+        var memoryAfter = GC.GetTotalMemory(forceFullCollection: true);

---

620-623: Inconsistent assertion pattern compared to other tests.

This uses inline assertion logic while other tests use the AssertPerformanceThreshold helper. Consider refactoring for consistency.

🔎 Suggested fix

-        if (maxMemory >= minMemory * 2 && maxMemory >= 100_000)
-        {
-            Assert.Fail($"Memory per component varies significantly at scale (min: {minMemory:N0}, max: {maxMemory:N0})");
-        }
+        // Verify memory per component remains stable (max should not be more than 2x min, unless both are small)
+        var memoryGrowthRatio = (double)maxMemory / minMemory;
+        if (minMemory > 50_000) // Only check ratio for meaningful memory values
+        {
+            AssertPerformanceThreshold(memoryGrowthRatio, 2.0,
+                $"Memory per component varies significantly at scale (min: {minMemory:N0}, max: {maxMemory:N0}, ratio: {memoryGrowthRatio:F2})");
+        }

---

701-705: Unnecessary assertion check.

The check components.Count != componentCount is redundant since the for-loop on lines 676-688 will always add exactly componentCount components. If RenderComponent throws, the test would fail before reaching this assertion.

🔎 Suggested fix

-        // Verify test completed successfully - all components were rendered
-        if (components.Count != componentCount)
-        {
-            Assert.Fail($"Expected {componentCount} components but got {components.Count}");
-        }
         AssertPerformanceThreshold(renderTime, 30000, "Rendering took too long");

---

11-17: Add CI-aware handling for performance test thresholds and selective execution.

The performance tests use hard-coded timing and memory thresholds with no consideration for CI environment variability. Currently:

• No [TestCategory] attributes for selective execution
• No environment-based threshold multipliers (thresholds are fixed: 50ms, 75ms, 25ms, etc.)
• No CI configuration to exclude or adjust performance tests

Consider:

1. Adding [TestCategory("Performance")] to allow selective execution
2. Detecting CI environment (e.g., via GITHUB_ACTIONS env variable) and applying multipliers to thresholds
3. Documenting expected performance test behavior differences between local and CI runs

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 74be421 and a8a4c9e.

📒 Files selected for processing (1)

• src/BlazorUI/Bit.BlazorUI.Tests/Components/Buttons/BitActionButtonPerformanceTests.cs

🧰 Additional context used

🧬 Code graph analysis (1)

src/BlazorUI/Bit.BlazorUI.Tests/Components/Buttons/BitActionButtonPerformanceTests.cs (2)

src/BlazorUI/Bit.BlazorUI.Tests/BunitTestContext.cs (1)

• BunitTestContext (9-49)

src/BlazorUI/Bit.BlazorUI/Components/Buttons/ActionButton/BitActionButton.razor.cs (1)

• BitActionButton (9-283)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build Bit.BlazorUI

🔇 Additional comments (3)

src/BlazorUI/Bit.BlazorUI.Tests/Components/Buttons/BitActionButtonPerformanceTests.cs (3)

157-192: Well-structured initial render tests with appropriate warm-up.

Good use of warm-up renders before timing measurements. The threshold values appear reasonable for the test scenarios.

---

438-449: Correct handling of closure variable capture.

Good use of a separate index variable to avoid the closure capture issue where the loop variable j would be captured by reference.

---

766-795: Well-designed helper utilities.

The ForceGarbageCollection method uses the standard double-collect pattern for thorough cleanup. The AssertPerformanceThreshold overloads effectively encapsulate the comparison logic and provide clear failure messages.