test(config): Add unit tests for config utilities; Update ESLint config to extend from eslint-config-yscope/jest for test files.
#135
Conversation
…to extend from `eslint-config-yscope/jest`.
|
Warning Rate limit exceeded@junhaoliao has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 42 minutes and 9 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the 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. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
WalkthroughThis pull request introduces several changes across multiple files. The Jest configuration in Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (5)
src/utils/config.ts (2)
106-111: Consider removing unreachable codeSince
testConfigthrows an error for theTHEMEkey, this case in the switch statement is unreachable. Consider removing it to improve code maintainability.- /* c8 ignore start */ - case CONFIG_KEY.THEME: - // Unexpected execution path. - break; - /* c8 ignore end */ /* c8 ignore next */ default: break;
58-60: Consider extracting the error message to a constantThe error message
"${key}" cannot be managed using these utilitiesis duplicated. Consider extracting it to a constant to maintain consistency and ease future updates.+const UNMANAGEABLE_CONFIG_ERROR = (key: string) => + `"${key}" cannot be managed using these utilities.`; // In testConfig - throw new Error(`"${key}" cannot be managed using these utilities.`); + throw new Error(UNMANAGEABLE_CONFIG_ERROR(key)); // In getConfig - throw new Error(`"${key}" cannot be managed using these utilities.`); + throw new Error(UNMANAGEABLE_CONFIG_ERROR(key));Also applies to: 149-151
test/utils/config.test.ts (3)
21-75: Consider centralizing error messages and test constants.While the test constants are well-defined, consider moving error messages and validation constants to a shared constants file to maintain consistency across the codebase.
Consider creating a new file
src/constants/errors.ts:export const CONFIG_ERRORS = { EMPTY_TIMESTAMP_KEY: 'Timestamp key cannot be empty.', EMPTY_LOG_LEVEL_KEY: 'Log level key cannot be empty.', INVALID_PAGE_SIZE: (maxSize: number) => `Page size must be greater than 0 and less than ${maxSize + 1}.`, UNMANAGED_THEME: (key: string) => `"${key}" cannot be managed using these utilities.` } as const;
76-104: Enhance type safety in the test helper function.The helper function could benefit from more explicit type definitions and error handling.
Consider this improvement:
-const runNegativeCases = (func: (input: ConfigUpdate) => Nullable<string>) => { +type TestFunction = (input: ConfigUpdate) => Nullable<string>; +type TestCase = { + input: ConfigUpdate | ConfigUpdate[]; + expected?: Nullable<string | string[]>; + throwable?: Error; +}; + +const runNegativeCases = (func: TestFunction) => { + const runSingleCase = ( + testInput: ConfigUpdate, + expectedResult?: Nullable<string> + ) => { + const result = func(testInput); + expect(result).toBe(expectedResult); + };
105-242: Consider improving test descriptions for clarity.While the test coverage is comprehensive, some test descriptions could be more specific about the scenarios they're testing.
Consider these improvements:
- Line 108: "should return null for valid decoder options" -> "should validate decoder options with all required fields"
- Line 180: "should log an error for invalid page size" -> "should log an error when page size is negative"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
jest.config.ts(1 hunks)package.json(2 hunks)src/utils/config.ts(4 hunks)test/utils/config.test.ts(1 hunks)
🔇 Additional comments (8)
jest.config.ts (2)
34-38: LGTM! Coverage threshold aligns with testing standards.
The addition of 100% coverage threshold for src/utils/config.ts maintains consistency with other utility files like math.ts.
34-38: Verify test coverage implementation.
Let's ensure the new coverage requirements are achievable and properly implemented.
✅ Verification successful
100% test coverage requirement is achievable and properly implemented
The test coverage requirements are reasonable and achievable based on the following evidence:
- The implementation in
config.tsis well-structured with clear, distinct code paths - The test file
config.test.tsdemonstrates comprehensive coverage:- Tests all config operations (get, set, test) for each config key
- Includes negative test cases for invalid inputs
- Verifies error conditions and edge cases
- Tests default values and localStorage interactions
- The only excluded code paths are properly marked with
/* c8 ignore */comments for unreachable defensive code
The existing test suite adequately covers:
- All branches in switch statements
- Validation logic for all config types
- Error handling scenarios
- Default value fallbacks
- Type conversions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence of test file and its coverage
# Check if test file exists
echo "Checking for config test file..."
fd "config.test.ts" test/utils/
# Check test coverage implementation
echo "Checking test coverage implementation..."
rg -A 5 "describe|test|it" test/utils/config.test.ts
# Check for any uncovered code markers
echo "Checking for coverage exclusion markers..."
rg "istanbul ignore" src/utils/config.ts
Length of output: 5580
Script:
#!/bin/bash
# Let's check the actual implementation to verify coverage feasibility
# Check the implementation of config.ts
echo "Checking config.ts implementation..."
cat src/utils/config.ts
# Check for any complex logic or edge cases
echo "Checking for complex patterns..."
ast-grep --pattern 'function $FNAME($$$) { $$$ }' src/utils/config.ts
# Check for conditional statements that might affect coverage
echo "Checking conditional statements..."
rg "if|switch|try" src/utils/config.ts
Length of output: 6619
package.json (2)
58-58: LGTM: Jest environment dependency added correctly
The addition of jest-environment-jsdom at version ^29.7.0 aligns perfectly with your existing Jest version and is essential for testing React components in a simulated browser environment.
101-101: LGTM: ESLint configuration simplified
The ESLint configuration for test files has been streamlined by extending from yscope/jest, which is a more maintainable approach than managing environment settings directly.
src/utils/config.ts (3)
58-60: LGTM: Clear and consistent error handling for theme configuration
The error handling for the THEME key is well-implemented and follows the function's documented behaviour.
149-151: LGTM: Consistent error handling pattern
The error handling for the THEME key maintains consistency with the pattern established in testConfig.
177-177: LGTM: Appropriate export of validation constant
Exporting MAX_PAGE_SIZE is appropriate as it represents a validation boundary that consumers might need to reference.
test/utils/config.test.ts (1)
1-20: LGTM! Environment and imports are well-structured.
The test environment and imports are properly configured for testing browser-specific functionality.
test/utils/config.test.ts
Outdated
| it("should retrieve page size once set", () => { | ||
| setConfig({key: CONFIG_KEY.PAGE_SIZE, value: VALID_PAGE_SIZE}); | ||
| const result = getConfig(CONFIG_KEY.PAGE_SIZE); | ||
| expect(result).toBe(VALID_PAGE_SIZE); | ||
| }); |
There was a problem hiding this comment.
Remove duplicate test case.
This test case is a duplicate of the one at lines 219-223.
Remove this duplicate test case:
- it("should retrieve page size once set", () => {
- setConfig({key: CONFIG_KEY.PAGE_SIZE, value: VALID_PAGE_SIZE});
- const result = getConfig(CONFIG_KEY.PAGE_SIZE);
- expect(result).toBe(VALID_PAGE_SIZE);
- });
There was a problem hiding this comment.
I agree with rabbit on this one
There was a problem hiding this comment.
@davemarco, thank you for confirming.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
|
discussed offline with @davemarco and he will review this later in the evening |
test/utils/config.test.ts
Outdated
| /** | ||
| * Negative test cases for `testConfig` and `setConfig` function. | ||
| */ | ||
| const NEGATIVE_CONFIG_CASES: Record<string, { |
There was a problem hiding this comment.
Why do this when we could just run them like positive cases?
There was a problem hiding this comment.
That's an attempt to deduplicate the test code for testConfig and setConfig, since everything that fails testConfig would also fail setConfig
There was a problem hiding this comment.
I see. I think the code is a bit hard to read. I suggest two options.
Option 1: Only run all the tests for testConfig() (and write them like normal jest tests), and then just have a single negative test for setConfig(). I think this will still get "100% coverage", but slightly less accurate since we are not testing all errors in setConfig().
Options 2: Try to refactor current code. There may be a cleaner approach something like below where all the tests are defined in a standard jest format, but I have not yet attempted myself.
const defineConfigTests = (func) => {
it('test1', () => {
expect(func(input1).toBe('number');
});
it('test2', () => {
expect(func(input2)).toBeGreaterThan(0);
});
etc...
};
There was a problem hiding this comment.
@junhaoliao This was my one annoying comment lol
There was a problem hiding this comment.
Right, sorry for missing that.
| case CONFIG_KEY.PAGE_SIZE: | ||
| if (0 >= value || MAX_PAGE_SIZE < value) { | ||
| result = `Page size must be greater than 0 and less than ${MAX_PAGE_SIZE + 1}.`; | ||
| } | ||
| break; | ||
| case CONFIG_KEY.THEME: |
There was a problem hiding this comment.
Question why do we not just let user set the theme in local storage? Would this not be simpler? See suggestion in setConfig()
There was a problem hiding this comment.
This was considered an impossible code path (i.e., calling testConfig or setConfig with CONFIG_KEY.THEME at any place would constitute an implementation error) because only JoyUI should have direct access on the theme config. We only created the theme-related types and localStorage keys to avoid type and key conflicts. With that said, i do see that we could be calling setConfig to set the theme once we implement the profile system, where we could be restoring theme name settings from a profile.
If you agree, we can implement CONFIG_KEY.THEME in the config utilities in preparation of the config profile system.
There was a problem hiding this comment.
I don't fully understand the comment "only JoyUI should have direct access on the theme config".
Like if we allow the theme to be set using setConfig, all it will do is persist the "light"/"dark"/"system" setting across sessions. If this isn't intended behaviour for some reason, then I'm okay leaving it as is.
There was a problem hiding this comment.
JoyUI has it own theme management system and they also store the config into localStorage so we do add an entry in our enums to avoid conflicts.
Right, we don't "allow the theme to be set using setConfig".
There was a problem hiding this comment.
Ah i finally understand what you mean. All good
test/utils/config.test.ts
Outdated
| /** | ||
| * Negative test cases for `testConfig` and `setConfig` function. | ||
| */ | ||
| const NEGATIVE_CONFIG_CASES: Record<string, { |
There was a problem hiding this comment.
I see. I think the code is a bit hard to read. I suggest two options.
Option 1: Only run all the tests for testConfig() (and write them like normal jest tests), and then just have a single negative test for setConfig(). I think this will still get "100% coverage", but slightly less accurate since we are not testing all errors in setConfig().
Options 2: Try to refactor current code. There may be a cleaner approach something like below where all the tests are defined in a standard jest format, but I have not yet attempted myself.
const defineConfigTests = (func) => {
it('test1', () => {
expect(func(input1).toBe('number');
});
it('test2', () => {
expect(func(input2)).toBeGreaterThan(0);
});
etc...
};
test/utils/config.test.ts
Outdated
| it("should retrieve page size once set", () => { | ||
| setConfig({key: CONFIG_KEY.PAGE_SIZE, value: VALID_PAGE_SIZE}); | ||
| const result = getConfig(CONFIG_KEY.PAGE_SIZE); | ||
| expect(result).toBe(VALID_PAGE_SIZE); | ||
| }); |
There was a problem hiding this comment.
I agree with rabbit on this one
| case CONFIG_KEY.PAGE_SIZE: | ||
| window.localStorage.setItem(LOCAL_STORAGE_KEY.PAGE_SIZE, value.toString()); | ||
| break; | ||
| /* c8 ignore start */ | ||
| case CONFIG_KEY.THEME: | ||
| // Unexpected execution path. |
There was a problem hiding this comment.
| // Unexpected execution path. | |
| window.localStorage.setItem(LOCAL_STORAGE_KEY.THEME, value.toString()); |
There was a problem hiding this comment.
Why dont we save the theme selection to local storage?
There was a problem hiding this comment.
Discussed at https://github.com/y-scope/yscope-log-viewer/pull/135/files#r1876734225 : we allocate the types and enums for theme config only to avoid name conflicts and we expected only JoyUI to read / write into localStorage, which might subject to change in the future.
There was a problem hiding this comment.
See my reply above https://github.com/y-scope/yscope-log-viewer/pull/135/files#r1871665037
junhaoliao
requested review from
davemarco
and removed request for
davemarco
test/utils/config.test.ts
Outdated
| expect(() => setConfig({ | ||
| key: CONFIG_KEY.THEME, | ||
| value: THEME_NAME.SYSTEM, | ||
| })).toThrow(`"${CONFIG_KEY.THEME}" cannot be managed using these utilities.`); |
There was a problem hiding this comment.
| })).toThrow(`"${CONFIG_KEY.THEME}" cannot be managed using these utilities.`); | |
| })).toThrow(UNMANAGED_THEME_THROWABLE); |
test/utils/config.test.ts
Outdated
| expect(() => getConfig(CONFIG_KEY.THEME)).toThrow( | ||
| `"${CONFIG_KEY.THEME}" cannot be managed using these utilities.` | ||
| ); |
There was a problem hiding this comment.
| expect(() => getConfig(CONFIG_KEY.THEME)).toThrow( | |
| `"${CONFIG_KEY.THEME}" cannot be managed using these utilities.` | |
| ); | |
| expect(() => getConfig(CONFIG_KEY.THEME)).toThrow(UNMANAGED_THEME_THROWABLE); |
package-lock.json
Outdated
There was a problem hiding this comment.
I think you updated all the dependencies in this PR. I think you should just install "jest-environment-jsdom" for this PR. Is it possible to revert the package-lock.json, and then just install jest-environment-jsdom?
There was a problem hiding this comment.
Here's how I added the dependency:
- Add the entry in
package.json. - Remove
node_modulesandpackage-lock.json. nvm use 22to make sure i'm using the latest version ofnpm.npm i.
Since the file is auto-generated, I think it's fine to leave it as-is. It might not be an issue after we merge #159
There was a problem hiding this comment.
I still think its better practice not to update all the dependencies in all PRs. Like we shouldnt remove the package-lock.json. The updates might break something unrelated to the PR, it is also harder for the reviewer to check the dependency changes. Anyways here is a script that should revert the updates and install jest-environment-jsdom.
git checkout 969ff35b2387bc -- package-lock.json
git checkout 969ff35b2387bc -- package.json
npm ci
npm i -D jest-environment-jsdom
| case CONFIG_KEY.PAGE_SIZE: | ||
| if (0 >= value || MAX_PAGE_SIZE < value) { | ||
| result = `Page size must be greater than 0 and less than ${MAX_PAGE_SIZE + 1}.`; | ||
| } | ||
| break; | ||
| case CONFIG_KEY.THEME: |
There was a problem hiding this comment.
I don't fully understand the comment "only JoyUI should have direct access on the theme config".
Like if we allow the theme to be set using setConfig, all it will do is persist the "light"/"dark"/"system" setting across sessions. If this isn't intended behaviour for some reason, then I'm okay leaving it as is.
| const cases = ( | ||
| Object.keys(VALID_DECODER_OPTIONS) as Array<keyof DecoderOptions> | ||
| ).map((key) => ({ | ||
| decoderOptions: { | ||
| key: CONFIG_KEY.DECODER_OPTIONS, | ||
| value: { | ||
| ...VALID_DECODER_OPTIONS, | ||
| [key]: "", | ||
| }, | ||
| } as ConfigUpdate, | ||
| expected: { | ||
| formatString: null, | ||
| logLevelKey: "Log level key cannot be empty.", | ||
| timestampKey: "Timestamp key cannot be empty.", | ||
| }[key], | ||
| })); |
There was a problem hiding this comment.
Should we wrap this code in another function like createNegativeCasesForDecoderOptions() with a description so more clear what this does?
There was a problem hiding this comment.
Good point. Since that piece of logic is not re-usable (at the moment) and not worth testable, would an inline comment suffice?
There was a problem hiding this comment.
Okay an inline comment is fine
test/utils/config.test.ts
Outdated
| value: -1, | ||
| }); | ||
|
|
||
| expect(result).toBe("Page size must be greater than 0 and less than 1000001."); |
There was a problem hiding this comment.
| expect(result).toBe("Page size must be greater than 0 and less than 1000001."); | |
| expect(result).toBe(`Page size must be greater than 0 and less than ${MAX_PAGE_SIZE + 1}.`); |
| @@ -168,6 +174,7 @@ export { | |||
| CONFIG_DEFAULT, | |||
| EXPORT_LOGS_CHUNK_SIZE, | |||
| getConfig, | |||
| MAX_PAGE_SIZE, | |||
There was a problem hiding this comment.
This currently isn't used, but will be used if you address my later comment. This is just a marker for me to remember in case you disagree with later comment. So ignore
| CONFIG_DEFAULT, | ||
| getConfig, | ||
| setConfig, | ||
| testConfig, |
There was a problem hiding this comment.
Required for my later comment.
| testConfig, | |
| testConfig, | |
| MAX_PAGE_SIZE, |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/utils/config.ts (1)
64-66: Consider usingfalse ==for boolean comparisonsAccording to coding guidelines, prefer
false == <expression>over!<expression>.- case CONFIG_KEY.THEME: - throw UNMANAGED_THEME_THROWABLE; + case CONFIG_KEY.THEME: { + throw UNMANAGED_THEME_THROWABLE; + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/utils/config.ts(5 hunks)test/utils/config.test.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- test/utils/config.test.ts
🧰 Additional context used
📓 Path-based instructions (1)
src/utils/config.ts (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
🔇 Additional comments (4)
src/utils/config.ts (4)
17-21: LGTM! Well-structured error handling for theme configurationThe introduction of
UNMANAGED_THEME_THROWABLEimproves error handling consistency and aligns with the design decision to delegate theme management to JoyUI.
112-117: LGTM! Appropriate handling of unreachable theme codeThe coverage ignore comments for the theme case were discussed and approved in previous reviews.
155-157: LGTM! Consistent theme error handlingThe error handling for theme configuration is consistent with
testConfig.
183-183: LGTM! Appropriate exports addedThe addition of
MAX_PAGE_SIZEandUNMANAGED_THEME_THROWABLEto exports is well-justified for validation and testing purposes.Also applies to: 187-187
There was a problem hiding this comment.
All were addressed except these 4:
- https://github.com/y-scope/yscope-log-viewer/pull/135/files/90c664e227cb46be065d781d010c8a0bf13f2e74#diff-053150b640a7ce75eff69d1a22cae7f0f94ad64ce9a855d
- https://github.com/y-scope/yscope-log-viewer/pull/135/files/1f21e68f02ce702e3df7b0e86f2ca4e53e3de35c#r1871665037
- https://github.com/y-scope/yscope-log-viewer/pull/135/files/90c664e227cb46be065d781d010c8a0bf13f2e74#r1904441700
- https://github.com/y-scope/yscope-log-viewer/pull/135/files/90c664e227cb46be065d781d010c8a0bf13f2e74#r1904447970
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
test/utils/config.test.ts (1)
44-59: Add inline comment to explain decoder options test cases.Based on past review discussions, an inline comment would help clarify the purpose of this code block.
Add a comment before line 44:
+ // Generate test cases for each decoder option field, ensuring empty values are properly validated const cases = ( Object.keys(VALID_DECODER_OPTIONS) as Array<keyof DecoderOptions> ).map((key) => ({
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
test/utils/config.test.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
test/utils/config.test.ts (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
🪛 GitHub Check: lint-check
test/utils/config.test.ts
[failure] 38-38:
This line has a comment length of 157. Maximum allowed is 100
🪛 GitHub Actions: lint
test/utils/config.test.ts
[warning] 38-38: This line has a comment length of 157. Maximum allowed is 100
🔇 Additional comments (2)
test/utils/config.test.ts (2)
1-21: LGTM! Well-organized imports and environment setup.The file is properly configured with jsdom environment and includes all necessary imports.
94-207: LGTM! Comprehensive test coverage.The test suites are well-structured and cover all necessary cases:
- Positive and negative test cases for all config types
- Proper cleanup between tests using
beforeEach- Thorough validation of localStorage interactions
- Proper error handling verification
test/utils/config.test.ts
Outdated
| const VALID_PAGE_SIZE = 5000; | ||
|
|
||
| /** | ||
| * Runs a set of negative config test cases using the given function. Prevents duplication of negative test cases for `setConfig` and `testConfig` functions. |
There was a problem hiding this comment.
Fix comment length to comply with linting rules.
The comment exceeds the maximum allowed length of 100 characters.
Split the comment into multiple lines:
-/** Runs a set of negative config test cases using the given function. Prevents duplication of negative test cases for `setConfig` and `testConfig` functions.
+/**
+ * Runs a set of negative config test cases using the given function. Prevents duplication
+ * of negative test cases for `setConfig` and `testConfig` functions.
*/📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| * Runs a set of negative config test cases using the given function. Prevents duplication of negative test cases for `setConfig` and `testConfig` functions. | |
| /** | |
| * Runs a set of negative config test cases using the given function. Prevents duplication | |
| * of negative test cases for `setConfig` and `testConfig` functions. | |
| */ |
🧰 Tools
🪛 GitHub Check: lint-check
[failure] 38-38:
This line has a comment length of 157. Maximum allowed is 100
🪛 GitHub Actions: lint
[warning] 38-38: This line has a comment length of 157. Maximum allowed is 100
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
test/utils/config.test.ts (2)
45-60: Add inline documentation for test case generation logic.The test case generation logic would benefit from an explanatory comment.
Add a comment before line 45:
+ // Generate test cases by mapping each decoder option key to a test case with an empty value + // and its expected error message const cases = (
81-92: Consider extracting error message as a constant.The error message for invalid page size is duplicated across test cases. Consider extracting it to a constant to maintain consistency and ease future updates.
Add at the top of the file with other constants:
+/** + * Error message for invalid page size validation. + */ +const INVALID_PAGE_SIZE_ERROR = (maxSize: number) => + `Page size must be greater than 0 and less than ${maxSize + 1}.`; const VALID_DECODER_OPTIONS: DecoderOptions = {Then update the test:
- expect(result).toBe(`Page size must be greater than 0 and less than ${MAX_PAGE_SIZE + 1}.`); + expect(result).toBe(INVALID_PAGE_SIZE_ERROR(MAX_PAGE_SIZE));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
test/utils/config.test.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
test/utils/config.test.ts (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
🪛 GitHub Check: lint-check
test/utils/config.test.ts
[failure] 38-38:
This line has a comment length of 157. Maximum allowed is 100
🪛 GitHub Actions: lint
test/utils/config.test.ts
[warning] 38-38: This line has a comment length of 157. Maximum allowed is 100
🔇 Additional comments (3)
test/utils/config.test.ts (3)
1-21: LGTM! Well-organized imports and environment setup.The imports are logically grouped, and the jsdom environment is correctly specified.
1-208: Great test coverage and organization!The test file is well-structured with comprehensive coverage of configuration utilities. The use of helper functions and constants makes the tests maintainable and readable.
🧰 Tools
🪛 GitHub Check: lint-check
[failure] 38-38:
This line has a comment length of 157. Maximum allowed is 100🪛 GitHub Actions: lint
[warning] 38-38: This line has a comment length of 157. Maximum allowed is 100
38-38:⚠️ Potential issueSplit the comment into multiple lines to comply with length limit.
The comment exceeds the maximum length of 100 characters.
Apply this diff:
-/** Runs a set of negative config test cases using the given function. Prevents duplication of negative test cases for `setConfig` and `testConfig` functions. +/** + * Runs a set of negative config test cases using the given function. Prevents duplication + * of negative test cases for `setConfig` and `testConfig` functions. + */Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Check: lint-check
[failure] 38-38:
This line has a comment length of 157. Maximum allowed is 100🪛 GitHub Actions: lint
[warning] 38-38: This line has a comment length of 157. Maximum allowed is 100
…om` without upgrading other dependencies.
|
Confirmed test cases still run sucessfully after changes. |
|
for title test(config): Add unit tests for config utilities; Update ESLint config to extend from |
junhaoliao
changed the title
eslint-config-yscope/jest.eslint-config-yscope/jest for test files.
Description
jest-environment-jsdom.eslint-config-yscope/jest.src/utils/config.ts.src/utils/config.ts.Validation performed
Summary by CodeRabbit
New Features
MAX_PAGE_SIZE, for configuration management.UNMANAGED_THEME_THROWABLE, for error handling.Bug Fixes
Documentation
Chores