Refactor: assertions

[lohanidamodar]

• replace assertEquals with assertSame

Summary by CodeRabbit

• Tests
  • Improved test coverage rigor across validation and email provider tests by upgrading assertions to enforce stricter type and value equality checks, enhancing test reliability and code quality assurance.

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

[coderabbitai]

Walkthrough

This pull request systematically replaces PHPUnit's assertEquals method with assertSame across 15 test files in the tests directory. The changes are applied consistently to assertions in email validation tests, canonical provider tests, and email validator tests. No modifications are made to test logic, control flow, or production code—only the assertion methods are updated to enforce strict type and value equality comparisons.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10-15 minutes

Rationale: This is a large but highly homogeneous refactoring where the identical pattern (assertEquals → assertSame) is applied across all affected files. The consistency of the change pattern significantly reduces review complexity. A reviewer can verify the pattern in a few representative files across different test categories and then scan the remainder for consistency.

Areas to note during review:

• Verify that all assertEquals calls have been converted to assertSame without exception or selective skipping
• Spot-check across different test categories (Canonicals, EmailTest, Validators) to ensure consistency
• Confirm no test logic or expected values were inadvertently modified during the refactoring

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

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

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Refactor: assertions' directly summarizes the main change: replacing assertEquals with assertSame across all test files for stricter type checking.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch refactor-assertions

---

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: 0

🧹 Nitpick comments (2)

tests/Validator/EmailDomainTest.php (1)

14-18: Stricter EmailDomain validator assertions are correct; consider boolean helpers

Switching these checks to assertSame (for booleans, strings, and the supported type/array flags) aligns with the validator’s concrete return types and only increases strictness—no behavior issues here. If you ever want to tweak for readability, you could replace assertSame(true/false, ...) with assertTrue / assertFalse, but that’s purely stylistic and outside this PR’s main goal.

Also applies to: 25-27, 29-35, 42-47, 54-54, 61-61, 68-68

tests/Validator/EmailCorporateTest.php (1)

14-21: EmailCorporate validator tests: stricter assertions are appropriate

All updated assertions now strictly compare expected booleans/strings against the validator outputs, matching the EmailCorporate API and improving type-safety of the tests. The corporate/free/disposable/non-string matrix and meta checks (description/type/isArray) retain their original intent.

Also applies to: 28-43, 50-60, 62-64, 71-75, 82-87, 94-94, 101-101, 108-108

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9c4c40c and 3d3a869.

📒 Files selected for processing (15)

• tests/Canonicals/Providers/FastmailTest.php (1 hunks)
• tests/Canonicals/Providers/GenericTest.php (1 hunks)
• tests/Canonicals/Providers/GmailTest.php (1 hunks)
• tests/Canonicals/Providers/IcloudTest.php (1 hunks)
• tests/Canonicals/Providers/OutlookTest.php (2 hunks)
• tests/Canonicals/Providers/ProtonmailTest.php (1 hunks)
• tests/Canonicals/Providers/WallaTest.php (1 hunks)
• tests/Canonicals/Providers/YahooTest.php (1 hunks)
• tests/Canonicals/Providers/YandexTest.php (1 hunks)
• tests/EmailTest.php (15 hunks)
• tests/Validator/EmailCorporateTest.php (1 hunks)
• tests/Validator/EmailDomainTest.php (1 hunks)
• tests/Validator/EmailLocalTest.php (1 hunks)
• tests/Validator/EmailNotDisposableTest.php (1 hunks)
• tests/Validator/EmailTest.php (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (11)

tests/Validator/EmailNotDisposableTest.php (3)

src/Emails/Validator/EmailDomain.php (4)

• isValid (32-45)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

src/Emails/Validator/EmailLocal.php (4)

• isValid (32-45)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

src/Emails/Validator/EmailNotDisposable.php (5)

• isValid (32-45)
• EmailNotDisposable (13-66)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

tests/Canonicals/Providers/YandexTest.php (2)

src/Emails/Canonicals/Provider.php (2)

• getCanonicalDomain (29-29)
• getSupportedDomains (34-34)

src/Emails/Canonicals/Providers/Yandex.php (2)

• getCanonicalDomain (41-44)
• getSupportedDomains (46-49)

tests/Validator/EmailTest.php (5)

src/Emails/Validator/Email.php (5)

• isValid (39-56)
• Email (13-77)
• getDescription (27-30)
• getType (73-76)
• isArray (63-66)

src/Emails/Validator/EmailCorporate.php (4)

• isValid (32-45)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

src/Emails/Validator/EmailDomain.php (4)

• isValid (32-45)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

src/Emails/Validator/EmailLocal.php (4)

• isValid (32-45)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

src/Emails/Validator/EmailNotDisposable.php (4)

• isValid (32-45)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

tests/Validator/EmailDomainTest.php (1)

src/Emails/Validator/EmailDomain.php (5)

• isValid (32-45)
• EmailDomain (13-66)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

tests/Canonicals/Providers/GmailTest.php (3)

src/Emails/Canonicals/Providers/Generic.php (2)

• getCanonicalDomain (36-40)
• getSupportedDomains (42-46)

src/Emails/Canonicals/Providers/Gmail.php (2)

• getCanonicalDomain (49-52)
• getSupportedDomains (54-57)

src/Emails/Email.php (1)

• getCanonicalDomain (316-326)

tests/Canonicals/Providers/GenericTest.php (2)

src/Emails/Canonicals/Providers/Generic.php (2)

• getCanonicalDomain (36-40)
• getSupportedDomains (42-46)

src/Emails/Canonicals/Provider.php (2)

• getCanonicalDomain (29-29)
• getSupportedDomains (34-34)

tests/Validator/EmailCorporateTest.php (1)

src/Emails/Validator/EmailCorporate.php (5)

• isValid (32-45)
• EmailCorporate (13-66)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

tests/Canonicals/Providers/YahooTest.php (1)

src/Emails/Canonicals/Providers/Yahoo.php (2)

• getCanonicalDomain (48-51)
• getSupportedDomains (53-56)

tests/EmailTest.php (4)

src/Emails/Email.php (9)

• get (129-132)
• getLocal (137-140)
• getDomain (145-148)
• getProvider (262-273)
• getSubdomain (278-282)
• Email (17-398)
• getFormatted (382-397)
• getCanonical (297-303)
• getCanonicalDomain (316-326)

src/Emails/Canonicals/Providers/Generic.php (2)

• getCanonical (22-34)
• getCanonicalDomain (36-40)

src/Emails/Canonicals/Providers/Gmail.php (2)

• getCanonical (27-47)
• getCanonicalDomain (49-52)

src/Emails/Canonicals/Providers/Outlook.php (2)

• getCanonical (39-56)
• getCanonicalDomain (58-61)

tests/Canonicals/Providers/WallaTest.php (2)

src/Emails/Canonicals/Providers/Walla.php (2)

• getCanonicalDomain (37-40)
• getSupportedDomains (42-45)

src/Emails/Email.php (1)

• getCanonicalDomain (316-326)

tests/Validator/EmailLocalTest.php (2)

src/Emails/Email.php (1)

• isValid (153-156)

src/Emails/Validator/EmailLocal.php (5)

• isValid (32-45)
• EmailLocal (13-66)
• getDescription (20-23)
• getType (62-65)
• isArray (52-55)

🔇 Additional comments (52)

tests/Canonicals/Providers/OutlookTest.php (1)

82-83: Strict assertions for Outlook canonicalization look good

Using assertSame for local/domain parts and supported domains (including canonical domain) is appropriate here and keeps checks strict without changing semantics. Parameter order is correct and messages are preserved.

Also applies to: 89-89, 109-109

tests/Canonicals/Providers/FastmailTest.php (1)

56-57: Fastmail canonical tests correctly tightened with assertSame

The switch to assertSame for local/domain and supported domains keeps the expectations identical while enforcing strict type/value comparison. No functional change, just stricter tests.

Also applies to: 63-63, 70-70

tests/Canonicals/Providers/IcloudTest.php (1)

59-60: iCloud canonicalization assertions are safely made strict

Updating the local/domain and supported-domain checks to assertSame is consistent with the provider behavior and just tightens type checking. Looks good.

Also applies to: 66-66, 73-73

tests/Validator/EmailNotDisposableTest.php (1)

14-18: EmailNotDisposable tests: assertSame usage is consistent and safe

All updated assertions now strictly compare the expected booleans/strings against the validator’s outputs, which matches the validator contracts and just tightens the checks. The broad matrix of valid/invalid/disposable/non-string cases remains unchanged in behavior.

Also applies to: 25-35, 37-39, 46-51, 57-62, 69-69, 76-76, 83-83

tests/Canonicals/Providers/YahooTest.php (1)

73-74: Yahoo provider tests correctly moved to strict identity assertions

Using assertSame for Yahoo’s canonical local/domain values and the supported-domains array fits the provider’s contract and enforces strict comparisons without altering the intended expectations.

Also applies to: 80-80, 87-87

tests/Canonicals/Providers/GmailTest.php (1)

56-57: Gmail canonical tests’ assertSame refactor is sound

The updated assertions for canonical local/domain and supported domains now use assertSame, which is appropriate for these string/array results and keeps the tests consistent with other provider suites.

Also applies to: 63-63, 69-69

tests/Canonicals/Providers/YandexTest.php (2)

55-56: Stricter canonical local/domain checks are appropriate

Comparing expected vs. actual canonical local and domain parts with assertSame matches the provider’s string return types and safely tightens these tests.

---

62-62: Canonical and supported domain assertions correctly use assertSame

Using assertSame for the canonical domain string and the supported domains array is consistent with the provider API and should not change behavior, only enforce strict typing.

Also applies to: 69-69

tests/Canonicals/Providers/ProtonmailTest.php (3)

59-60: Canonical local/domain assertions safely tightened

Switching to assertSame for canonical local and domain comparisons aligns with the expected string types and improves test strictness without changing intent.

---

66-66: Canonical domain check correctly uses strict comparison

getCanonicalDomain() is expected to return the exact string 'protonmail.com', so assertSame is the right choice here.

---

73-73: Supported domains array comparison is compatible with assertSame

Comparing the expected domains list to $domains via assertSame is fine given both sides are simple string arrays in a fixed order.

tests/Canonicals/Providers/WallaTest.php (3)

60-61: Canonical local/domain checks now correctly enforce identity

Using assertSame on $result['local'] and $result['domain'] is consistent with the provider returning strings and just tightens the tests.

---

67-67: Canonical domain assertion is safely stricter

Asserting 'walla.co.il' via assertSame against getCanonicalDomain() matches the provider contract and is appropriate.

---

73-73: Supported domains array assertion works with assertSame

The supported domains list is a plain, ordered string array, so switching to assertSame preserves behavior while enforcing strict equality.

tests/EmailTest.php (20)

15-29: Strict checks for basic accessors and flags look good

For test_valid_email, all expectations (strings and booleans) match the Email API, so using assertSame here is a safe tightening of the tests.

---

36-42: Subdomain-related assertions correctly use assertSame

In test_email_with_subdomain, strict comparisons on full address, local, domain, provider, subdomain, and hasSubdomain() all align with their expected string/bool types.

---

48-55: Gmail address flags and provider checks are safely stricter

test_gmail_email now uses assertSame on string and boolean results, which matches the intended types and should only increase test robustness.

---

61-67: Disposable email flags behave correctly under strict assertions

In test_disposable_email, strict true/false checks for disposable/free/corporate status still reflect the validator contracts and are appropriate.

---

73-79: Special-character email behavior remains unchanged with assertSame

For test_email_with_special_characters, strict comparisons for address components and validity flags are type-correct and maintain the original test intent.

---

85-90: Hyphen-handling tests correctly tightened

test_email_with_hyphens now strictly compares expected strings and booleans; this is consistent with Email’s API.

---

97-102: Underscore-handling tests work well with strict equality

test_email_with_underscores uses assertSame for strings and booleans, matching expected return types without changing semantics.

---

109-114: Numeric local/domain tests safely use assertSame

In test_email_with_numbers, all expectations are strings/bools, so strict identity checks are appropriate.

---

121-126: Multiple-dot handling remains correctly specified under assertSame

test_email_with_multiple_dots relies on string and boolean results; using assertSame here is correct and clearer about types.

---

133-138: Multiple subdomain behavior validated with strict results

test_email_with_multiple_subdomains now strictly asserts provider/subdomain strings and hasSubdomain() bool, which matches the Email implementation.

---

145-149: Formatted output tests correctly tightened

In test_email_formatted, getFormatted() is expected to return strings for each format; assertSame enforces that precisely.

---

156-156: Normalization test benefits from strict string comparison

test_email_normalization’s use of assertSame on the normalized email string is appropriate and will catch any type drift.

---

203-203: Invalid-local and invalid-domain flag checks correctly use assertSame

The invalid email tests that assert hasValidLocal()/hasValidDomain() are now strictly comparing to false, which is consistent with these methods’ boolean contracts.

Also applies to: 210-210, 217-217, 225-225, 233-233, 240-240

---

247-249: Additional invalid-domain/local scenarios remain accurate under strict booleans

All these tests expect precise true/false results for domain/local validity; assertSame correctly encodes that requirement without altering intent.

Also applies to: 255-255, 262-262, 269-269, 276-276, 283-283, 290-290, 297-297

---

323-324: Free provider flags correctly tightened

In test_free_email_providers, strict checks for isFree() and isCorporate() (true/false) per provider are appropriate and consistent with expected boolean returns.

---

346-347: Disposable provider flags use assertSame appropriately

test_disposable_email_providers now enforces strict true/false for isDisposable() and isCorporate(), aligning with the API.

---

366-368: Corporate provider flags are correctly asserted with strict booleans

In test_corporate_email_providers, strict false/false/true checks reflect the expected corporate classification behavior.

---

405-405: Canonicalization tests safely upgraded to strict string comparisons

Across the various test_get_unique_*_aliases and related canonicalization tests, using assertSame($expected, $email->getCanonical(), ...) is fully compatible with the string return type of getCanonical() and simply tightens equality checks.

Also applies to: 456-456, 503-503, 540-540, 577-577, 612-612, 646-646, 708-708, 762-762

---

842-842: Canonical domain expectations correctly use assertSame

In test_get_canonical_domain, strict comparisons between expected canonical domain (or null) and getCanonicalDomain() match the ?string API and are appropriate.

---

850-850: Cross-provider canonical behavior tests remain valid with strict assertions

test_get_unique_with_different_providers now uses assertSame for all canonical strings across Gmail, Outlook, Yahoo, and generic providers; this is consistent with the design and keeps the tests robust.

Also applies to: 853-853, 857-857, 860-860, 864-864, 867-867

tests/Canonicals/Providers/GenericTest.php (3)

65-66: Generic canonical local/domain checks correctly use assertSame

For test_get_canonical, strictly comparing the expected and actual local/domain strings ensures these generic cases don’t accidentally change type or casing.

---

73-73: Empty canonical domain assertion is accurate and strict

test_get_canonical_domain now asserts an empty string via assertSame, which directly matches Generic::getCanonicalDomain()’s documented behavior.

---

80-80: Supported domains empty-array check works with assertSame

Using assertSame([], $domains) in test_get_supported_domains is appropriate given the generic provider supports all domains and returns an empty array marker.

tests/Validator/EmailLocalTest.php (6)

14-19: Valid local-part tests correctly use strict booleans

In test_valid_email_local, switching to assertSame(true, ...) for isValid() ensures the validator truly returns a boolean and matches the expected behavior.

---

26-31: Invalid local-part scenarios remain correct under strict false checks

test_invalid_email_local now strictly asserts false for invalid locals; this aligns with the EmailLocal contract and does not change semantics.

---

38-43: Non-string input tests appropriately tightened

In test_non_string_input, strict false checks for various non-string values make it explicit that the validator rejects non-string inputs.

---

50-50: Description string comparison is safely stricter

test_validatordescription now uses assertSame on the description string, which is appropriate for this fixed literal.

---

57-57: Validator type string check correctly uses assertSame

test_validatortype’s strict comparison to 'string' matches the validator’s getType() contract.

---

64-64: isArray flag assertion is accurate with strict false

test_validator_is_array correctly enforces that isArray() returns false via assertSame.

tests/Validator/EmailTest.php (9)

14-21: Valid email cases now use strict true checks

In test_validemail, assertSame(true, $validator->isValid(...)) aligns with the boolean return type and only tightens the assertions.

---

28-47: Invalid email scenarios and special cases correctly tightened

test_invalidemail now strictly distinguishes true vs. false for each edge case (including consecutive hyphens and exclamation-mark local parts), matching the documented behavior of the underlying validation.

---

53-58: Non-string input handling is clearly asserted as false

test_non_string_input’s use of assertSame(false, ...) for all non-string values makes the validator’s contract explicit and is semantically correct.

---

65-65: Description string assertion correctly uses assertSame

In test_validatordescription, strict comparison of the description string is appropriate for this fixed literal value.

---

72-72: Type string assertion is safely stricter

test_validatortype now strictly compares 'string' to getType(), which matches the validator’s implementation.

---

79-79: isArray flag correctly asserted as false with strict equality

test_validator_is_array’s assertSame(false, $validator->isArray()) is consistent with the non-array nature of this validator.

---

86-87: allowEmpty=false behavior is correctly enforced with assertSame

test_allow_empty_disabled strictly checks that empty strings are invalid and normal emails are valid, matching the constructor flag semantics.

---

94-97: allowEmpty=true behavior remains accurate under strict checks

In test_allow_empty_enabled, the combination of true for empty and valid emails and false for invalid emails is enforced precisely with assertSame.

---

103-104: Default allowEmpty behavior is correctly asserted

test_allow_empty_default_behavior now strictly verifies that the default treats empty as invalid and normal emails as valid, in line with the Email validator’s default configuration.