feat: add tests for tool-object script #3265
Conversation
vishvamsinh28
requested review from
derberg,
akshatnema,
magicmatatjahu,
anshgoyalevil,
Mayaleeeee and
asyncapi-bot-eve
as code owners
✅ Deploy Preview for asyncapi-website ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-3265--asyncapi-website.netlify.app/ |
anshgoyalevil
added
the
gsoc
WalkthroughThe changes encompass modifications to three files: Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant ToolsObject
participant Axios
User->>ToolsObject: call convertTools(data)
ToolsObject->>ToolsObject: try {
ToolsObject->>Axios: fetch tools data
Axios-->>ToolsObject: return data
ToolsObject->>ToolsObject: process data
}
ToolsObject-->>User: return finalToolsObject
ToolsObject->>User: catch error
ToolsObject-->>User: throw error message
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: 0
🧹 Outside diff range and nitpick comments (15)
scripts/tools/tools-object.js (3)
50-52: LGTM: Improved error handling with try-catch blockThe addition of the try-catch block around the entire function body significantly improves error handling. Moving the initializations inside the try block ensures that any errors during these steps are caught as well.
One minor suggestion:
Consider adding more specific error handling by creating custom error types or adding more context to the error message. This could help with debugging and error tracking in the future.
Example:
} catch (err) { throw new Error(`Error processing tools: ${err.message}. Stack: ${err.stack}`); }Also applies to: 111-114
63-108: LGTM: Improved inner try-catch block and error handlingThe flattened structure of the inner try-catch block improves readability and maintainability. The improved error logging provides more context for debugging, which is excellent.
One suggestion for further improvement:
Consider using a more descriptive variable name instead of
errin the catch block. This can provide more context about the type of error being caught.Example:
} catch (toolProcessingError) { console.error(toolProcessingError); throw toolProcessingError; }
Line range hint
1-117: Overall assessment: Significant improvements in error handling and code qualityThe changes made to this file represent a substantial improvement in error handling, code formatting, and overall readability. Key improvements include:
- Enhanced error handling with try-catch blocks
- Improved function signatures with default parameters
- Standardized code formatting and indentation
- Better error logging for debugging purposes
These changes will contribute to better maintainability and robustness of the codebase. Great job on these improvements!
For future enhancements, consider:
- Implementing more granular error handling with custom error types
- Adding unit tests to cover the error handling scenarios introduced in this update
- Documenting the error handling approach for other developers working on this file
tests/tools/tools-object.test.js (5)
36-53: LGTM: Well-structured test suite setup and initial test cases.The test suite is properly set up with a
describeblock andbeforeEachfor mock clearing. The first two test cases forcreateToolObjectcover basic functionality well.Consider adding test cases for edge cases, such as:
- When both toolFile.description and repoDescription are undefined.
- When isAsyncAPIrepo is false.
55-72: LGTM: Comprehensive tests for convertTools function.The test cases for the
convertToolsfunction cover important scenarios, including correct data conversion and assignment to the "Others" category. The use of mocked Axios responses and detailed assertions is commendable.Consider adding the following assertions to strengthen the tests:
- In the first test (lines 55-62), verify that the correct URL is passed to axios.get.
- In the second test (lines 64-72), also check that the tool is not present in any other category.
74-90: LGTM: Good coverage of error handling for invalid tool files.The test case for handling invalid .asyncapi-tool files is well-implemented. The use of console.error spy to check for logged errors is a good practice.
Consider the following improvements:
- Instead of just logging errors, consider throwing or returning an error object from the
convertToolsfunction. This would allow for more robust error handling in the application code.- Add a test case to verify that the function continues processing other tools even when one tool file is invalid.
117-137: LGTM: Good coverage of network and JSON validation errors.The test cases for handling network errors and JSON schema validation failures are well-implemented. They cover critical error scenarios that could occur in real-world usage.
Consider adding the following error scenarios:
- Test case for a partially valid JSON (e.g., missing some required fields but otherwise valid).
- Test case for a timeout error from Axios.
- Test case for an unexpected HTTP status code (e.g., 404 or 500) from the API.
139-177: LGTM: Comprehensive testing of JSON parsing and property validation.The test cases for handling invalid JSON format and missing required tool properties are well-implemented. They cover important error scenarios related to data parsing and validation.
Consider the following improvements:
- Group related test cases together. For example, move these JSON parsing and property validation tests closer to the other JSON schema validation test (around line 127).
- Consider using
beforeEachto reset mocks for each test, especially for the utils module mock, to ensure test isolation.- Add a test case for a scenario where some optional properties are missing but all required properties are present.
tests/fixtures/toolsObjectData.js (7)
19-53: LGTM: Well-defined test data for different stages of tool processingThe constants
mockToolFileContent,toolFileT1, andexpectedObjectT1provide a clear representation of the different stages in processing a tool file. They are consistent and well-structured.Consider adding a comment explaining the relationship between these constants to improve readability.
You could add a comment like this before line 19:
// The following constants represent different stages of processing a tool file: // 1. mockToolFileContent: Raw content of the tool file // 2. toolFileT1: Parsed version of the tool file // 3. expectedObjectT1: Final processed version with additional properties
59-80: LGTM: Well-defined test case for handling missing propertiesThe constants
toolFileT2andexpectedObjectT2provide a good test case for handling missing properties and default values during tool processing. They will be useful for ensuring robust parsing and processing of tool files.For consistency with the previous test case, consider adding a comment explaining the purpose of these constants.
You could add a comment like this before line 59:
// The following constants represent a test case for handling missing properties: // 1. toolFileT2: Parsed version of a tool file with some properties missing // 2. expectedObjectT2: Expected final processed version with default values and additional properties
82-104: LGTM: Comprehensive test case for tool categorizationThe
expectedObjectT3constant provides a comprehensive test case for a function that categorizes tools. It includes both a specific category and an "Others" category, which is good for testing edge cases.To improve clarity, consider adding a comment explaining the purpose and structure of this constant.
You could add a comment like this before line 82:
// expectedObjectT3: Represents the expected output of a function that categorizes tools // It includes a specific category (Category1) and an "Others" category for comprehensive testing
106-132: LGTM: Comprehensive test cases for handling unknown categoriesThe constants
dataWithUnknownCategory,toolFileContent,dataWithUnknownCategoryOnce, andunknownToolFileContentprovide thorough test cases for handling tools with unknown categories. They cover different aspects of this scenario, which is crucial for robust error handling.To improve organization and readability, consider grouping these related constants together in the file.
You could move the
dataWithUnknownCategoryOnceandunknownToolFileContentconstants (currently at lines 204-243) to be adjacent to the other unknown category constants (after line 132). This would group related test cases together, making the file structure more logical and easier to navigate.Also applies to: 204-243
134-161: LGTM: Comprehensive test cases for handling invalid tool dataThe constants
invalidToolFileContent,invalidToolData,invalidToolFileContentJSON, andinvalidJsonContentprovide a good range of test cases for handling various types of invalid tool data. This variety is crucial for ensuring robust error handling in the tool processing logic.To improve organization and clarity:
- Consider grouping these related constants together in the file.
- The naming of
invalidToolFileContentandinvalidToolFileContentJSONis very similar and might be confusing. Consider renaming for clarity.Suggested improvements:
- Move the
invalidToolFileContentJSONandinvalidJsonContentconstants (currently at lines 245-261) to be adjacent to the other invalid tool constants (after line 161).- Rename the constants for clarity, for example:
invalidToolFileContent->invalidToolFileContentWithExtraFieldinvalidToolFileContentJSON->invalidToolFileContentMalformedJSON
This would group related test cases together and make the purpose of each constant clearer.Also applies to: 245-261
263-268: LGTM: Good test case for handling missing propertiesThe
missingToolPropertyContentconstant provides a good test case for handling tool files with missing required properties. This is an important edge case to test.For consistency with other constants in the file, consider using a JSON-like string format instead of YAML.
You could modify the constant to use a JSON-like string format, like this:
const missingToolPropertyContent = ` { "title": "Missing Property Tool", "description": "This tool is missing required properties", "links": { "repoUrl": "https://github.com/asyncapi/missing-property" } }`;This would make it consistent with the format used in other constants like
mockToolFileContent.
1-292: Overall: Well-structured and comprehensive test fixtures with minor improvement opportunitiesThis file provides a robust set of test fixtures covering a wide range of scenarios for tool processing, including valid cases, edge cases, and error cases. The variety and completeness of the test data will enable thorough testing of the tool processing logic.
Some suggestions for minor improvements:
- Group related constants together (e.g., all constants related to unknown categories, all constants related to invalid data).
- Add comments to explain the purpose of groups of related constants.
- Ensure consistency in the format of string constants (e.g., using JSON-like strings consistently).
- Consider renaming some constants for clarity, especially where names are very similar.
These changes would further enhance the readability and maintainability of this test fixture file.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- scripts/tools/tools-object.js (2 hunks)
- tests/fixtures/toolsObjectData.js (1 hunks)
- tests/tools/tools-object.test.js (1 hunks)
🔇 Additional comments (10)
scripts/tools/tools-object.js (3)
28-28: LGTM: Improved function signature with default parametersThe updated function signature with default parameter values enhances code readability and provides better flexibility when calling the function. This change aligns with best practices in JavaScript.
54-60: LGTM: Improved code formatting and readabilityThe standardized formatting throughout the
convertToolsfunction significantly improves code readability and maintainability. The consistent indentation and spacing make the code easier to understand and follow.Also applies to: 85-98
117-117: LGTM: Improved export statement formattingThe reformatted export statement improves code consistency and readability. This change aligns with common JavaScript formatting practices.
tests/tools/tools-object.test.js (3)
1-34: LGTM: Imports and mock setup are well-structured.The imports, mock data setup, and mocking of external dependencies (Axios and categoryList) are comprehensive and follow good testing practices. This setup provides a solid foundation for the test suite.
92-115: LGTM: Thorough testing of duplicate tools and category assignment.The test cases for handling duplicate tools and ensuring single assignment to the "Others" category are well-implemented. They cover important edge cases in tool categorization and demonstrate good use of mocked responses.
The deduplication logic in the "Others" category test (lines 103-115) is particularly well done, ensuring that the same tool is not added multiple times.
1-178: Overall: Excellent test coverage with room for minor enhancements.This test suite for the tools-object script is comprehensive and well-structured. It covers the main functionality, error scenarios, and edge cases. The use of mocking, particularly for Axios and the categoryList, is commendable.
To further improve the test suite:
- Consider adding more edge cases as suggested in the individual comments.
- Reorganize some tests to group related scenarios together.
- Ensure consistent use of
beforeEachfor mock resets across all tests.- Consider adding integration tests that cover the interaction between
convertToolsandcreateToolObjectfunctions.Great job on creating a robust test suite!
tests/fixtures/toolsObjectData.js (4)
1-17: LGTM: Well-structured mock data for GitHub API responseThe
mockDataconstant provides a good representation of a GitHub API response for a tool. It includes all necessary properties and is well-formed, making it suitable for testing purposes.
55-57: LGTM: Useful constants for repository-specific testsThe constants
repositoryUrl,repoDescription, andisAsyncAPIrepoprovide specific values for testing repository-related functionality. They are consistent with the data in other constants and will be useful for targeted tests.
163-202: LGTM: Well-structured test cases for handling duplicate toolsThe constants
duplicateToolDataandduplicateToolFileContentprovide well-structured test cases for handling duplicate tool entries. The separation of API response data and file content allows for thorough testing of duplicate handling at different stages of processing.
270-292: LGTM: Comprehensive and well-organized module exportsThe module exports are comprehensive, including all constants defined in the file. This provides maximum flexibility for importing and using these test fixtures in various test scenarios. The exports are well-organized and easy to read.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (1)
tests/build-tools.test.js (1)
Line range hint
1-89: Consider reorganizing the test suite for better structureThe new test case integrates well with the existing structure. However, to improve the overall organization and readability of the test suite, consider the following suggestions:
- Group related test cases together using
describeblocks.- Move common setup and teardown logic into
beforeAllandafterAllhooks within thesedescribeblocks.- Use more descriptive test case names to clearly indicate what each test is verifying.
Here's a suggested restructure:
describe('buildTools', () => { // ... (existing setup code) describe('Successful scenarios', () => { it('should extract, convert, combine tools, and write to file', async () => { // ... (existing test case) }); }); describe('Error handling', () => { it('should handle getData error', async () => { // ... (existing test case) }); it('should handle file write errors for invalid paths', async () => { // ... (new test case) }); }); // ... (existing teardown code) });This structure:
- Groups test cases into logical sections.
- Makes it easier to add new test cases in the appropriate sections.
- Improves readability and maintainability of the test suite.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- tests/build-tools.test.js (1 hunks)
- tests/fixtures/toolsObjectData.js (1 hunks)
- tests/tools/tools-object.test.js (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/tools/tools-object.test.js
🔇 Additional comments (9)
tests/build-tools.test.js (1)
Line range hint
1-89: Overall assessment: Good addition with room for improvementThe introduction of the new test case for handling file write errors is a valuable addition to the test suite. It improves the coverage of error scenarios and helps ensure the robustness of the
buildToolsfunction.However, there are opportunities to enhance both the new test case and the overall structure of the test suite:
- The new test case could be more comprehensive in its assertions and cleanup.
- The overall test suite could benefit from better organization using
describeblocks.These improvements would lead to a more maintainable and thorough test suite. Despite these suggestions, the current implementation is functional and adds value to the codebase.
tests/fixtures/toolsObjectData.js (8)
49-51: Verify the value of 'hasCommercial' in 'expectedObjectT1'In
expectedObjectT1, thehasCommercialproperty is set totrue. Ensure that this reflects the intended test case scenario and that it aligns with the corresponding tool file data.
77-78: Mismatch in 'hasCommercial' value in 'expectedObjectT2'In
expectedObjectT2, thehasCommercialproperty is set tofalse, whereas inexpectedObjectT1, it istrue. Verify whether this difference is intentional based on the test case specifications.
70-71: 'Description' field missing in 'toolFileT2' but present in 'expectedObjectT2'In
toolFileT2(line 59~), there is nodescriptionfield provided. However,expectedObjectT2includes adescriptionfield sourced fromrepoDescription. Verify that your code is designed to default the description to the repository description when none is provided in the tool file.
106-122: Handle unknown categories in 'dataWithUnknownCategory'The
dataWithUnknownCategoryobject includes tools categorized under'UnknownCategory'. Ensure that your tests check how the code handles tools with unknown categories and that it aligns with the expected behavior (e.g., assigning them to an 'Others' category or excluding them).
145-161: Test handling of invalid tool data in 'invalidToolData'The
invalidToolDatarepresents a tool with an invalid field (invalidField). Confirm that your tests validate the schema properly and that your code correctly identifies and handles such invalid entries.
163-192: Ensure proper handling of duplicate tool entriesThe
duplicateToolDatacontains duplicate entries for the same tool. Verify that your code can detect duplicates and handles them according to the requirements, such as merging them, deduplicating, or raising an error.
245-254: Test parsing of malformed tool file contentThe
toolFileMalformedJSONconstant contains malformed YAML content (missing a colon afterfilters). Ensure that your tests cover parsing errors and that your code gracefully handles exceptions thrown due to invalid file formats.
255-275: Export all defined constantsReview the
module.exportsobject to confirm that all the defined constants are exported correctly. Missing exports could lead to tests failing due to undefined references.
| @@ -86,4 +86,5 @@ describe('buildTools', () => { | |||
| expect(err.message).toMatch(/ENOENT|EACCES/); | |||
| } | |||
| }); | |||
|
|
|||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance the file write error test case
The new test case for handling file write errors is a valuable addition. However, consider the following improvements to make it more robust and comprehensive:
- Add cleanup steps to remove any files that might have been created during the test.
- Make the error message check more specific to ensure it's catching the intended error.
- Verify that no files were written to the valid paths.
Here's a suggested improvement:
it('should handle file write errors', async () => {
axios.get.mockResolvedValue({ data: mockExtractData });
const invalidPath = '/invalid_dir/tools.json';
const validPaths = [manualToolsPath, toolsPath, tagsPath];
try {
await buildTools(invalidPath, ...validPaths);
fail('Expected an error to be thrown');
} catch (err) {
expect(err.code).toMatch(/ENOENT|EACCES/);
// Verify no files were written to valid paths
validPaths.forEach(path => {
expect(fs.existsSync(path)).toBe(false);
});
}
// Cleanup any files that might have been created
[invalidPath, ...validPaths].forEach(path => {
if (fs.existsSync(path)) {
fs.unlinkSync(path);
}
});
});This improved version:
- Uses
err.codeinstead oferr.messagefor more specific error checking. - Verifies that no files were written to the valid paths.
- Includes cleanup steps to remove any files that might have been created.
- Uses
fail()to ensure an error is thrown.
|
|
||
| const repositoryUrl = 'https://github.com/asyncapi/example-repo'; | ||
| const repoDescription = 'Example repository'; | ||
| const isAsyncAPIrepo = true; |
There was a problem hiding this comment.
Rename constant to match property name
The constant isAsyncAPIrepo is defined, but in your expected objects, the property is named isAsyncAPIOwner. To maintain consistency across your codebase, consider renaming the constant to isAsyncAPIOwner.
Apply this diff to rename the constant:
-const isAsyncAPIrepo = true;
+const isAsyncAPIOwner = true;📝 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.
| const isAsyncAPIrepo = true; | |
| const isAsyncAPIOwner = true; |
| isAsyncAPIOwner: true | ||
| } |
There was a problem hiding this comment.
Inconsistent property name: 'isAsyncAPIOwner' vs 'isAsyncAPIrepo'
In expectedObjectT1, the property isAsyncAPIOwner is used, whereas the constant defined is isAsyncAPIrepo (line 57~). For consistency, consider using the same naming convention for both the constant and the property.
Apply this diff to rename the property for consistency:
hasCommercial: true,
- isAsyncAPIOwner: true
+ isAsyncAPIrepo: true📝 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.
| isAsyncAPIOwner: true | |
| } | |
| hasCommercial: true, | |
| isAsyncAPIrepo: true | |
| } |
This PR adds tests for tools-object.js script
Summary by CodeRabbit
New Features
Bug Fixes
Tests
convertToolsandcreateToolObjectfunctions, covering various scenarios including error handling and data conversion.buildToolsfunction.