Skip to content

Conversation

@cyprain-okeke
Copy link
Contributor

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-28610

📔 Objective

Fix this error below :

FormatForProvider_ComplexScenario_HandlesAllLineTypes [1 ms]
Assert.Equal() Failure: Strings differ

Expected: "1 × Tax (at $0.00 / month)"
Actual: "1 × Tax (at $8.00 / month)"
↑ (pos 14)

at Bit.Core.Test.Billing.Extensions.InvoiceExtensionsTests
.FormatForProvider_ComplexScenario_HandlesAllLineTypes()
in /Users/oscar/Code/server/test/Core.Test/Billing/Extensions/InvoiceExtensionsTests.cs:line 389

at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

📸 Screenshots

⏰ Reminders before review

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Protected functional changes with optionality (feature flags)
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

  • 👍 (:+1:) or similar for great changes
  • 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
  • ❓ (:question:) for questions
  • 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
  • 🎨 (:art:) for suggestions / improvements
  • ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
  • 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
  • ⛏ (:pick:) for minor or nitpick changes

@cyprain-okeke cyprain-okeke requested a review from a team as a code owner November 21, 2025 15:01
@claude
Copy link
Contributor

claude bot commented Nov 21, 2025

Claude finished @cyprain-okeke's task —— View job


Code Review

Summary

This PR fixes a failing test by wrapping the test method in a culture-specific context to ensure consistent decimal formatting across different system locales. The test was failing because decimal formatting (e.g., $8.00) depends on the current thread's culture, causing inconsistent results on machines with different regional settings.

Findings

Finding 1: Test expectation change requires verification

💭 The test expectation changed from $0.00 to $8.00 for a Tax line item with Amount = 800 cents. While $8.00 correctly matches the implementation's calculation logic (InvoiceExtensions.cs:53-54), this raises an important question: was the original $0.00 expectation intentional (e.g., a regression test) or a test data error? Please verify this change represents correct business behavior and document the reasoning in the PR description.

Finding 2: Culture setting approach could be more robust

🎨 Using a try-finally block with culture restoration is the correct approach. However, consider using CultureInfo.InvariantCulture instead of new CultureInfo("en-US") for unit tests. Invariant culture is specifically designed for culture-independent formatting and makes the intent clearer - you want consistent formatting regardless of system locale, not specifically US formatting. (See inline comment on line 367)

Finding 3: PR description gaps

⚠️ The PR description has two notable gaps:

  1. Root cause explanation: The objective mentions the symptom (expected vs actual values) but doesn't explain that the root cause is culture-dependent decimal formatting varying by system locale
  2. Missing test plan: Document how you verified the fix (e.g., ran tests locally, tested with different culture settings, confirmed all related tests pass)

Finding 4: Consider checking for similar issues

💭 Other tests in this file that format currency values might have similar culture-dependency issues. Consider reviewing tests like FormatForProvider_TaxLineWithoutPriceInfo_CalculatesPrice (line 221) and others that assert formatted decimal strings.

Good Practices Observed

  • Proper try-finally pattern ensures culture is always restored after test execution
  • Clear inline comments explaining the purpose of culture setting

Action Items

  1. ⚠️ Critical: Verify and document that $8.00 is the correct expected behavior (not just making the test pass)
  2. 🎨 Consider using CultureInfo.InvariantCulture for clearer test intent (see inline comment)
  3. ⚠️ Add test plan to PR description with verification steps
  4. 💭 Review other tests in the file for similar culture-dependent formatting issues

try
{
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Copy link
Contributor

Choose a reason for hiding this comment

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

🎨 Consider using CultureInfo.InvariantCulture instead of new CultureInfo("en-US") for unit tests. Invariant culture is specifically designed for culture-independent operations and makes the intent clearer - you want consistent formatting regardless of system locale, not specifically US formatting.

Suggested change
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
Thread.CurrentThread.CurrentUICulture = CultureInfo.InvariantCulture;

Assert.Equal(5, result.Count);
Assert.Equal("5 × Manage service provider (at $6.00 / month)", result[0]);
Assert.Equal("10 × Manage service provider (at $4.00 / month)", result[1]);
Assert.Equal("1 × Tax (at $8.00 / month)", result[2]);
Copy link
Contributor

Choose a reason for hiding this comment

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

💭 This assertion now expects $8.00, which correctly matches the test data (line 381: Amount = 800 cents = $8.00). The original test expected $0.00.

Can you confirm this change represents correct business logic? Was the original $0.00 expectation:

  • A test data error that should have been 0 cents?
  • An intentional regression test?
  • Or is $8.00 the correct expected behavior?

This is important to verify we're fixing the test correctly, not just making it pass.

@github-actions
Copy link
Contributor

Logo
Checkmarx One – Scan Summary & Details751735c4-1d64-46a8-8186-c1676fa2c569

Great job! No new security vulnerabilities introduced in this pull request

@codecov
Copy link

codecov bot commented Nov 21, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.99%. Comparing base (08ce693) to head (f68c57e).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6622      +/-   ##
==========================================
- Coverage   53.00%   52.99%   -0.01%     
==========================================
  Files        1909     1909              
  Lines       84828    84828              
  Branches     7634     7634              
==========================================
- Hits        44961    44955       -6     
- Misses      38115    38119       +4     
- Partials     1752     1754       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants