Refactor TestAllInSameYear class#3131
Conversation
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughRefactors the test helper in Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (27)📓 Common learnings📚 Learning: 2025-04-05T04:47:27.213ZApplied to files:
📚 Learning: 2025-11-08T05:09:56.159ZApplied to files:
📚 Learning: 2025-04-05T06:49:06.217ZApplied to files:
📚 Learning: 2025-09-18T03:19:23.722ZApplied to files:
📚 Learning: 2025-11-08T05:36:32.788ZApplied to files:
📚 Learning: 2025-06-15T11:52:39.572ZApplied to files:
📚 Learning: 2025-09-10T14:35:54.603ZApplied to files:
📚 Learning: 2025-04-05T04:29:38.042ZApplied to files:
📚 Learning: 2025-05-06T21:07:11.577ZApplied to files:
📚 Learning: 2025-05-09T18:36:09.607ZApplied to files:
📚 Learning: 2025-09-27T05:11:09.476ZApplied to files:
📚 Learning: 2025-09-20T12:21:50.877ZApplied to files:
📚 Learning: 2025-06-18T17:01:58.067ZApplied to files:
📚 Learning: 2025-04-03T12:36:41.201ZApplied to files:
📚 Learning: 2025-09-17T09:07:56.459ZApplied to files:
📚 Learning: 2025-09-17T09:07:56.459ZApplied to files:
📚 Learning: 2025-09-10T16:17:30.428ZApplied to files:
📚 Learning: 2025-04-05T04:50:40.752ZApplied to files:
📚 Learning: 2025-03-23T16:59:25.794ZApplied to files:
📚 Learning: 2025-04-05T04:33:53.254ZApplied to files:
📚 Learning: 2025-08-12T17:16:54.497ZApplied to files:
📚 Learning: 2025-08-19T19:47:21.735ZApplied to files:
📚 Learning: 2025-09-14T16:03:13.558ZApplied to files:
📚 Learning: 2025-09-10T13:39:34.625ZApplied to files:
📚 Learning: 2025-09-14T16:05:55.205ZApplied to files:
📚 Learning: 2025-06-14T11:04:31.180ZApplied to files:
🪛 Ruff (0.14.8)tests/test_utils.py119-119: Prefer (TRY004) 119-119: Avoid specifying long messages outside the exception class (TRY003) 121-121: Avoid specifying long messages outside the exception class (TRY003) 126-126: Avoid specifying long messages outside the exception class (TRY003) 128-128: Missing return type annotation for private function Add return type annotation: (ANN202) ⏰ Context from checks skipped due to timeout of 300000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (4)
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. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #3131 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 306 306
Lines 18167 18167
Branches 2301 2301
=========================================
Hits 18167 18167 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
tests/test_utils.py (2)
128-142: Parallelization likely dropped subdivision coverage (dict values are ignored).
entity_listis typed asdict[str, list[str]], but you only iterate keys and never testsubdiv=.... If the old test validated subdivisions too, this is a behavior regression (even if runtime improves). Based on learnings, coverage is typically prioritized in this repo, so I’d restore it.One way (keep base + each subdiv as separate work items):
def _check_holidays_years( self, entity_func: Callable[..., HolidayBase], entity_list: dict[str, list[str]] -): +)-> None: """ @@ """ - args_list = [(entity, entity_func, self.years) for entity in entity_list] + args_list: list[tuple[str, str | None, Callable[..., HolidayBase], set[int]]] = [] + for entity, subdivs in entity_list.items(): + args_list.append((entity, None, entity_func, self.years)) + for subdiv in subdivs: + args_list.append((entity, subdiv, entity_func, self.years)) with ProcessPoolExecutor() as executor: - list(executor.map(self._check_single_entity_worker, args_list)) + list(executor.map(self._check_single_entity_worker, args_list))…and update the worker signature to accept/forward
subdiv(same pattern for both per-year and full-range calls).
108-142: Static methods are picklable on spawn, but module-level workers remain the safer pattern.The test already runs on Windows/macOS (spawn) in CI and passes reliably, so this isn't causing failures. That said, best practice suggests moving
_check_single_entity_workerto module scope anyway—it's cleaner, avoids any potential brittleness, and is the standard pattern for multiprocessing workers. The current approach works but is less defensive than needed.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
tests/test_utils.py(3 hunks)
🧰 Additional context used
🧠 Learnings (26)
📓 Common learnings
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_french_polynesia.py:19-22
Timestamp: 2025-11-08T05:09:56.159Z
Learning: In the vacanza/holidays project's test framework (PR #2881 onwards), the base class CommonCountryTests provides a default test_no_holidays implementation that automatically tests years=start_year - 1 for standard PUBLIC category cases. Individual country test files should only override test_no_holidays when the country supports additional non-PUBLIC categories (GOVERNMENT, WORKDAY, OPTIONAL, etc.) with different start years requiring separate validation.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_faroe_islands.py:16-16
Timestamp: 2025-11-08T05:36:32.788Z
Learning: In PR #2881 onwards, the vacanza/holidays project moved to centralized alias testing via the `check_aliases` method in `tests/common.py`. Individual country test files no longer need to import country code aliases (e.g., FO, FRO for Faroe Islands) or define `test_country_aliases` methods. The common test framework automatically validates all aliases by dynamically importing them from the registry and calling `assertAliases`.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2530
File: tests/countries/test_andorra.py:23-28
Timestamp: 2025-05-06T21:07:11.577Z
Learning: In the holidays project, test methods for country holidays follow a standard form where year ranges are explicitly recreated in each test method rather than being stored as class variables, to maintain consistency across all country tests.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2386
File: tests/countries/test_nepal.py:499-536
Timestamp: 2025-04-05T06:49:06.217Z
Learning: In the holidays project, test files follow a dual testing approach: individual methods test specific holidays across multiple years, while comprehensive year-specific tests (e.g., `test_2025`) verify all holidays for a specific year in a single assertion. Both approaches serve different testing purposes and complement each other.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_algeria.py:28-30
Timestamp: 2025-09-18T03:19:23.722Z
Learning: In the vacanza/holidays project, tests now use self.start_year and self.end_year from the TestCase class instead of country-specific aliases (like DZ.start_year) for start_year and end_year references. This approach provides the test framework with better control over test year ranges rather than being tied to specific country start years.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_albania.py:40-42
Timestamp: 2025-09-04T08:54:35.319Z
Learning: In the vacanza/holidays project test files, extract holiday name strings to local variables only when they are reused multiple times within the same test method (e.g., used in both assertHolidayName and assertNoHolidayName calls). When a holiday name is used only once, keep it inline rather than extracting it to a variable for the sake of consistency.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py:209-209
Timestamp: 2025-09-14T17:17:14.387Z
Learning: In tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py, the explicit loop iteration pattern for subdivision-specific holiday checks (like Anniversary Day for TA subdivision) is intentionally preferred over using assertSubdivTa helper methods, as confirmed by PPsyrius.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2642
File: tests/countries/test_france.py:24-27
Timestamp: 2025-06-18T10:10:46.158Z
Learning: The holidays library prioritizes full test coverage over performance in test suites. Modern library-wide standards favor comprehensive testing across all subdivisions and wide year ranges (e.g., 1803-2050 for France) to ensure thorough validation, even if it creates many test objects.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2537
File: tests/countries/test_finland.py:23-26
Timestamp: 2025-05-09T18:36:09.607Z
Learning: The holidays project prioritizes complete historical coverage in tests, verifying holidays from their first year of observance (e.g., 1853 for Finland) through future projections, rather than using shorter sliding windows.
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2829
File: tests/countries/test_canada.py:291-296
Timestamp: 2025-08-19T19:47:21.735Z
Learning: In the holidays library, HolidayBase objects automatically populate years on-demand when expand=True (the default). When checking dates from years not initially in the years range, those years are automatically populated via the logic at line 646 in holiday_base.py: "if self.expand and dt.year not in self.years:". This means tests can check dates outside the initial year range without needing separate holiday instances.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_brazil.py:28-30
Timestamp: 2025-09-10T14:35:54.603Z
Learning: In the holidays project, the test_no_holidays method should test ALL supported_categories (via categories=CountryClass.supported_categories) rather than just the default PUBLIC category, to ensure comprehensive validation that no holidays exist before start_year across any supported category including OPTIONAL and subdivision categories.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2794
File: tests/calendars/test_julian.py:35-36
Timestamp: 2025-08-12T17:16:54.497Z
Learning: In the vacanza/holidays project calendar tests (Thai, Ethiopian, Julian, etc.), the established testing pattern for validation methods is to use simple for loops like `for year in known_data_dict:` followed by `self.assertEqual(expected, actual)` without using unittest's subTest feature. This pattern is consistently maintained across all calendar test files.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2601
File: tests/countries/test_mongolia.py:128-156
Timestamp: 2025-06-15T11:52:39.572Z
Learning: In the vacanza/holidays project tests, when testing holidays that span multiple consecutive days across many years (like Mongolia's National Festival spanning July 11-13), prefer explicit for loops over complex nested generator expressions with unpacking. The explicit loops are more readable, easier to maintain, and better communicate the testing intent even though the Big O complexity is equivalent.
📚 Learning: 2025-04-05T04:47:27.213Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-11-08T05:09:56.159Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_french_polynesia.py:19-22
Timestamp: 2025-11-08T05:09:56.159Z
Learning: In the vacanza/holidays project's test framework (PR #2881 onwards), the base class CommonCountryTests provides a default test_no_holidays implementation that automatically tests years=start_year - 1 for standard PUBLIC category cases. Individual country test files should only override test_no_holidays when the country supports additional non-PUBLIC categories (GOVERNMENT, WORKDAY, OPTIONAL, etc.) with different start years requiring separate validation.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T06:49:06.217Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2386
File: tests/countries/test_nepal.py:499-536
Timestamp: 2025-04-05T06:49:06.217Z
Learning: In the holidays project, test files follow a dual testing approach: individual methods test specific holidays across multiple years, while comprehensive year-specific tests (e.g., `test_2025`) verify all holidays for a specific year in a single assertion. Both approaches serve different testing purposes and complement each other.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-18T03:19:23.722Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_algeria.py:28-30
Timestamp: 2025-09-18T03:19:23.722Z
Learning: In the vacanza/holidays project, tests now use self.start_year and self.end_year from the TestCase class instead of country-specific aliases (like DZ.start_year) for start_year and end_year references. This approach provides the test framework with better control over test year ranges rather than being tied to specific country start years.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-11-08T05:36:32.788Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_faroe_islands.py:16-16
Timestamp: 2025-11-08T05:36:32.788Z
Learning: In PR #2881 onwards, the vacanza/holidays project moved to centralized alias testing via the `check_aliases` method in `tests/common.py`. Individual country test files no longer need to import country code aliases (e.g., FO, FRO for Faroe Islands) or define `test_country_aliases` methods. The common test framework automatically validates all aliases by dynamically importing them from the registry and calling `assertAliases`.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-10T14:35:54.603Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_brazil.py:28-30
Timestamp: 2025-09-10T14:35:54.603Z
Learning: In the holidays project, the test_no_holidays method should test ALL supported_categories (via categories=CountryClass.supported_categories) rather than just the default PUBLIC category, to ensure comprehensive validation that no holidays exist before start_year across any supported category including OPTIONAL and subdivision categories.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-05-06T21:07:11.577Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2530
File: tests/countries/test_andorra.py:23-28
Timestamp: 2025-05-06T21:07:11.577Z
Learning: In the holidays project, test methods for country holidays follow a standard form where year ranges are explicitly recreated in each test method rather than being stored as class variables, to maintain consistency across all country tests.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-08-19T19:47:21.735Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2829
File: tests/countries/test_canada.py:291-296
Timestamp: 2025-08-19T19:47:21.735Z
Learning: In the holidays library, HolidayBase objects automatically populate years on-demand when expand=True (the default). When checking dates from years not initially in the years range, those years are automatically populated via the logic at line 646 in holiday_base.py: "if self.expand and dt.year not in self.years:". This means tests can check dates outside the initial year range without needing separate holiday instances.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-05-09T18:36:09.607Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2537
File: tests/countries/test_finland.py:23-26
Timestamp: 2025-05-09T18:36:09.607Z
Learning: The holidays project prioritizes complete historical coverage in tests, verifying holidays from their first year of observance (e.g., 1853 for Finland) through future projections, rather than using shorter sliding windows.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-06-15T11:52:39.572Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2601
File: tests/countries/test_mongolia.py:128-156
Timestamp: 2025-06-15T11:52:39.572Z
Learning: In the vacanza/holidays project tests, when testing holidays that span multiple consecutive days across many years (like Mongolia's National Festival spanning July 11-13), prefer explicit for loops over complex nested generator expressions with unpacking. The explicit loops are more readable, easier to maintain, and better communicate the testing intent even though the Big O complexity is equivalent.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:29:38.042Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:85-86
Timestamp: 2025-04-05T04:29:38.042Z
Learning: For testing holiday implementations in the vacanza/holidays repository, recommend using `from tests.common import CommonCountryTests` as the base class instead of directly using `unittest.TestCase` to maintain consistency with project conventions and leverage common test utilities.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-06-18T17:01:58.067Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2642
File: tests/countries/test_wallis_and_futuna.py:19-23
Timestamp: 2025-06-18T17:01:58.067Z
Learning: In the vacanza/holidays repository, the standard pattern for test class setUpClass methods is `super().setUpClass(HolidayClass)` or `super().setUpClass(HolidayClass, years=...)` where HolidayClass is passed as the first argument. This is the correct signature that matches the CommonCountryTests.setUpClass method which accepts test_class as the first parameter after cls. Pylint warnings about parameter count mismatch are false positives when comparing against TestCase.setUpClass instead of the immediate parent CommonCountryTests.setUpClass.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-27T05:11:09.476Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2952
File: tests/countries/test_norway.py:25-27
Timestamp: 2025-09-27T05:11:09.476Z
Learning: In the vacanza/holidays project, the standard pattern for handling deprecation warnings in country test files is to use `warnings.simplefilter("ignore", category=DeprecationWarning)` in the setUp() method. This pattern is consistently used across multiple major country test files (USA, UK, Germany, France, Portugal, New Zealand, Norway) that have deprecated subdivisions and test them using `self.assertDeprecatedSubdivisions()`.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:50:40.752Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:31-49
Timestamp: 2025-04-05T04:50:40.752Z
Learning: For Turkmenistan holiday tests, use this class structure: `class TestTurkmenistan(CommonCountryTests, TestCase)` with imports `from unittest import TestCase`, `from holidays.countries import Turkmenistan, TM, TKM`, and `from tests.common import CommonCountryTests`. Ensure to call `super().setUp()` in the setUp method.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-03-23T16:59:25.794Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2362
File: tests/test_ical.py:31-40
Timestamp: 2025-03-23T16:59:25.794Z
Learning: In the holidays library's `TestIcalExporter` class, initializing `ICalExporter` with `None` is intentional. Using a mock object instead breaks tests because the constructor performs attribute validation with `getattr(self.holidays, "language", None)` which returns a mock with a mock object instead of `None`, causing validation failures. The approach isolates file operation tests from iCal generation logic.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:33:53.254Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:33:53.254Z
Learning: For Turkmenistan holiday tests, recommend using CommonCountryTests as the base class rather than unittest.TestCase to follow project conventions, be consistent with other country test files, and gain access to common test utilities.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-08-12T17:16:54.497Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2794
File: tests/calendars/test_julian.py:35-36
Timestamp: 2025-08-12T17:16:54.497Z
Learning: In the vacanza/holidays project, test methods that iterate over dictionaries of test data (like calendar drift tests) follow the established pattern without using unittest's subTest, as evidenced by the Thai calendar tests and maintained consistently across similar test structures.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-17T09:07:56.459Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_paraguay.py:134-139
Timestamp: 2025-09-17T09:07:56.459Z
Learning: In the vacanza/holidays project, for holidays that start from a specific year (not the country's start_year), the standard pattern is to use `range(specific_year, self.end_year)` rather than `self.full_range` with year conditions. This maintains consistency across the codebase and clearly separates the holiday period from the pre-holiday period using `assertNoHolidayName(name, range(self.start_year, specific_year))`.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-17T09:07:56.459Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_paraguay.py:134-139
Timestamp: 2025-09-17T09:07:56.459Z
Learning: In the vacanza/holidays project, when testing holidays that start from a specific year (not the country's start_year), the standard pattern is to use `range(specific_year, self.end_year)` for the holiday dates and `assertNoHolidayName(name, range(self.start_year, specific_year))` for the gap period. Using `self.full_range` with year conditions like `if year >= specific_year` is not the established pattern and would be inconsistent with the codebase.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-06-14T11:04:31.180Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2609
File: holidays/countries/nauru.py:57-60
Timestamp: 2025-06-14T11:04:31.180Z
Learning: In the holidays library, the base `HolidayBase._populate()` method already includes a guard clause that prevents holiday population methods like `_populate_public_holidays()` from being called when the year is before `start_year` or after `end_year`. Therefore, individual country implementations do not need to add their own guard clauses for years before independence or other start dates.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-03T14:05:10.592Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_aruba.py:77-79
Timestamp: 2025-09-03T14:05:10.592Z
Learning: The assertNoHolidayName helper method in the vacanza/holidays test framework accepts both individual years (scalars) and iterables of years, making calls like assertNoHolidayName(name, AW.start_year, range(2023, 2050)) valid where AW.start_year is a single integer year.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-14T16:03:13.558Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_barbados.py:21-23
Timestamp: 2025-09-14T16:03:13.558Z
Learning: In tests/countries/test_barbados.py, using years_non_observed=range(2000, 2024) is intentional because all observed holiday examples fall within 2001-2023, making this range appropriate for limiting testing to years where observed holidays actually exist in the test data.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-08-12T17:16:54.497Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2794
File: tests/calendars/test_julian.py:35-36
Timestamp: 2025-08-12T17:16:54.497Z
Learning: In the vacanza/holidays project calendar tests (Thai, Ethiopian, Julian, etc.), the established testing pattern for validation methods is to use simple for loops like `for year in known_data_dict:` followed by `self.assertEqual(expected, actual)` without using unittest's subTest feature. This pattern is consistently maintained across all calendar test files.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-14T17:17:14.387Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py:209-209
Timestamp: 2025-09-14T17:17:14.387Z
Learning: In tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py, the explicit loop iteration pattern for subdivision-specific holiday checks (like Anniversary Day for TA subdivision) is intentionally preferred over using assertSubdivTa helper methods, as confirmed by PPsyrius.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-14T16:05:55.205Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_iran.py:28-28
Timestamp: 2025-09-14T16:05:55.205Z
Learning: In tests/countries/test_iran.py, using years=(self.start_year - 1, 2102) in the no-holiday test is intentional because Iran uses the Persian Calendar which has specific supported year range constraints, and 2102 represents the upper limit of the Persian Calendar's supported range, not just an arbitrary far-future date.
Applied to files:
tests/test_utils.py
🪛 Ruff (0.14.8)
tests/test_utils.py
119-119: Avoid specifying long messages outside the exception class
(TRY003)
121-121: Prefer TypeError exception for invalid type
(TRY004)
121-121: Avoid specifying long messages outside the exception class
(TRY003)
126-126: Avoid specifying long messages outside the exception class
(TRY003)
128-128: Missing return type annotation for private function _check_holidays_years
Add return type annotation: None
(ANN202)
⏰ Context from checks skipped due to timeout of 300000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test Python 3.14 on windows-latest
|
Proposed change
Parallelizes
TestAllInSameYeartests by testing individual countries/markets separately instead of all of them sequentially.Type of change
holidaysfunctionality in general)Checklist
make checklocally; all checks and tests passed.