feat: add test for combine tools script #3136
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-3136--asyncapi-website.netlify.app/ |
| @@ -106,7 +105,7 @@ const getFinalTool = async (toolObject) => { | |||
|
|
|||
| // Combine the automated tools and manual tools list into single JSON object file, and | |||
| // lists down all the language and technology tags in one JSON file. | |||
| const combineTools = async (automatedTools, manualTools) => { | |||
| const combineTools = async (automatedTools, manualTools, toolsPath, tagsPath) => { | |||
There was a problem hiding this comment.
what does tagspath signify??
| JSON.stringify({ languages: languageList, technologies: technologyList }), | ||
| ) | ||
| fs.writeFileSync(toolsPath,JSON.stringify(finalTools)); | ||
| fs.writeFileSync(tagsPath,JSON.stringify({ languages: languageList, technologies: technologyList }),) | ||
| } | ||
|
|
||
| module.exports = { combineTools } |
tests/tools/combine-tools.test.js
Outdated
| const tagsData = readJSON(tagsPath); | ||
| expect(tagsData.languages).toContainEqual(expect.objectContaining({ name: 'NewLanguage' })); | ||
| }); | ||
| }); |
anshgoyalevil
added
the
gsoc
scripts/build-tools.js
Outdated
| @@ -14,7 +14,7 @@ const buildTools = async () => { | |||
| resolve(__dirname, '../config', 'tools-automated.json'), | |||
| JSON.stringify(automatedTools, null, ' ') | |||
| ); | |||
| await combineTools(automatedTools, manualTools); | |||
| await combineTools(automatedTools, manualTools, resolve(__dirname, '../../config', 'tools.json'), resolve(__dirname, '../../config', 'all-tags.json')); | |||
There was a problem hiding this comment.
Can we do it in a more better way, instead of passing filePath here? Try to refactor tools scripts instead of manually passing filePaths for tags file.
| }); | ||
|
|
||
| it('should combine tools and create correct JSON files', async () => { | ||
| await combineTools(automatedTools, manualTools, toolsPath, tagsPath); |
There was a problem hiding this comment.
try to add this function call in a try/catch block here to monitor if we are receiving any error or not.
| }); | ||
|
|
||
|
|
||
| it('should log validation errors to console.error', async () => { |
There was a problem hiding this comment.
Errors shouldn't be validated via console messages. You should formally return a error using Promise.reject.
scripts/build-tools.js
Outdated
| @@ -6,15 +6,19 @@ const manualTools = require('../config/tools-manual.json') | |||
| const fs = require('fs'); | |||
| const { resolve } = require('path'); | |||
|
|
|||
| let toolsPath = resolve(__dirname, '../../config', 'tools.json') | |||
There was a problem hiding this comment.
is using let a good option here?
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3136 +/- ##
==========================================
+ Coverage 49.14% 56.85% +7.70%
==========================================
Files 21 21
Lines 647 649 +2
==========================================
+ Hits 318 369 +51
+ Misses 329 280 -49 ☔ View full report in Codecov by Sentry. |
|
@vishvamsinh28 You need to check what caused this workflow to fail Additionally, can we upload base reports for each PR, or does that work as a one time process for a new repo. Kindly research on that and fix |
![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 (3)
scripts/build-tools.js (1)
Line range hint
9-11: Consider using 'const' instead of 'let'The variables
githubExtractDataandautomatedToolsare declared usinglet, but they are not reassigned after their initial assignment. To improve code clarity and prevent accidental reassignment, consider usingconstinstead:- let githubExtractData = await getData(); - let automatedTools = await convertTools(githubExtractData); + const githubExtractData = await getData(); + const automatedTools = await convertTools(githubExtractData);This change aligns with best practices for variable declaration in JavaScript and makes the code's intent clearer.
tests/build-tools.test.js (2)
Line range hint
1-89: Consider enhancing test coverageWhile the existing tests cover the main scenarios, consider adding the following to improve coverage:
- Test with empty input files.
- Test with malformed JSON in input files.
- Test the behavior when the
categoryListis empty or contains unexpected data.- Verify the structure and content of the output files more thoroughly.
These additional tests would help ensure the robustness of the
buildToolsfunction across various edge cases.
3-5: Improve visibility of mock dataWhile using mock data from external files is a good practice for keeping tests clean, it can sometimes make it harder to understand the tests at a glance. Consider adding brief comments or examples of the mock data structure directly in this test file. This would make it easier for developers to understand the test scenarios without having to switch between multiple files.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- scripts/build-tools.js (2 hunks)
- tests/build-tools.test.js (3 hunks)
🧰 Additional context used
🔇 Additional comments (4)
scripts/build-tools.js (1)
25-28: 🛠️ Refactor suggestionConsider the implications of changing from
path.resolve()topath.join()The switch from
path.resolve()topath.join()might alter how paths are constructed. Whilepath.resolve()always returns an absolute path,path.join()simply concatenates path segments. This change could make the paths relative to the current working directory instead of absolute paths.Please verify that this change doesn't negatively impact how these paths are used in other parts of the codebase. If absolute paths are required, consider using
path.resolve(__dirname, ...)instead.To verify the impact of this change, run the following script:
Additionally, as per a previous review comment, consider refactoring the tools scripts to avoid manually passing file paths. This could involve creating a configuration file or using environment variables to manage these paths centrally.
✅ Verification successful
Path resolution change verified; no impact detected
The change from
path.resolve()topath.join()inscripts/build-tools.jshas been verified. Searches across the codebase show thatautomatedToolsPath,manualToolsPath,toolsPath, andtagsPathare used consistently within their modules and tests, with no negative impacts detected.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for usage of these file paths in other parts of the codebase # Test: Search for usage of these file paths echo "Searching for usage of automatedToolsPath:" rg "automatedToolsPath" --type js echo "Searching for usage of manualToolsPath:" rg "manualToolsPath" --type js echo "Searching for usage of toolsPath:" rg "toolsPath" --type js echo "Searching for usage of tagsPath:" rg "tagsPath" --type jsLength of output: 9115
tests/build-tools.test.js (3)
27-31: Improved path handling withpath.join()The change from
path.resolve()topath.join()for constructing file paths is a good improvement.path.join()is more predictable and safer for cross-platform compatibility, as it doesn't resolve to an absolute path likeresolve()might in some cases. This change aligns with best practices for path manipulation in Node.js.
81-81: Consistent path handling for invalid pathThe update to use
path.join()for constructing theinvalidPathis consistent with the earlier changes. This maintains the test's intention of creating an invalid path while aligning with the improved path handling approach.
Line range hint
1-89: Overall assessment: Good improvements with room for enhancementThe changes to path handling using
path.join()are positive and improve cross-platform compatibility. The overall test structure remains robust, covering main scenarios effectively. To further enhance this test suite, consider:
- Implementing the suggested additional test cases for better coverage.
- Improving the visibility of mock data structures within the test file.
- Adding more detailed assertions to verify the structure and content of output files.
These enhancements would contribute to a more comprehensive and maintainable test suite.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
tests/tools/combine-tools.test.js (1)
30-32: Remove unused mock for 'ajv-formats'The mock for
'ajv-formats'is defined but not utilized in the tests. Removing this unused mock will clean up the code.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- tests/build-tools.test.js (1 hunks)
- tests/tools/combine-tools.test.js (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/build-tools.test.js
🧰 Additional context used
🔇 Additional comments (18)
tests/tools/combine-tools.test.js (18)
1-22: Module imports and data setups are well-structuredThe required modules and fixtures are correctly imported, providing a solid foundation for the tests.
34-43: Mocks for 'tags-color' are correctly set upThe color configurations for languages and technologies are well-defined, aiding in the consistency of test data.
45-50: 'categoryList' mock is properly configuredThe mocked categories provide a clear structure for testing category-related functionalities.
52-52: Efficient JSON reading withreadJSONhelperThe
readJSONfunction enhances code readability and reuse by encapsulating JSON file reading.
54-76: Test initialization and cleanup are properly handledUsing
beforeAllandafterAllensures that tests are isolated and the environment is clean, preventing side effects between tests.
78-88: Comprehensive test for combining tools and generating JSON filesThe test correctly verifies that the
combineToolsfunction creates the expected files with the right properties.
90-96: Correct handling of tools with missing dataThe test ensures that tools lacking language or technology information are still processed appropriately.
98-105: Tools are sorted alphabetically as expectedVerifying the alphabetical sorting of tools by title confirms that the sorting functionality works correctly.
107-120: Validation errors are effectively loggedThe test successfully checks that validation errors are captured and logged, aiding in debugging and error tracking.
122-136: Proper handling of multiple and new languagesThe test confirms that tools with multiple languages, including new ones, are processed, and tags are updated accordingly.
138-162: New languages and technologies are added correctlyThe test ensures that unfamiliar languages and technologies are added to the tags, maintaining the integrity of the tag system.
164-180: Addition of new languages is handled properlyBy testing with a new language, the code demonstrates flexibility in accommodating growth in the list of supported languages.
182-198: Valid tool objects are processed accuratelyThe test validates that tools with complete and correct data are handled as expected, reinforcing confidence in the normal operation of
combineTools.
200-208: Handling tools withoutrepoUrlgracefullyThe absence of
repoUrldoesn't cause issues, and the test confirms that theisAsyncAPIrepoproperty is managed correctly.
210-221: Refactor error handling using Jest's.rejects.toThrow()The previous review comment suggesting refactoring this test to use
.rejects.toThrow()instead of a try/catch block is still applicable.
223-233: Simplify error assertions with Jest's.rejects.toThrow()The prior suggestion to use
.rejects.toThrow()for cleaner error handling remains valid for this test case.
235-245: Use.rejects.toThrow()for clearer asynchronous error testsThe earlier recommendation to refactor this test using Jest's
.rejects.toThrow()method is still pertinent.
247-258: Refactor to simplify error handling with JestThe test can be streamlined by adopting
.rejects.toThrow()as previously suggested.
| jest.mock('ajv', () => { | ||
| return jest.fn().mockImplementation(() => ({ | ||
| compile: jest.fn().mockImplementation(() => (data) => data.title !== 'Invalid Tool'), | ||
| })); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance the AJV mock for comprehensive validation testing
The current mock of the ajv validator simplifies validation to only check the title field. To improve test coverage and ensure robustness, consider using the actual ajv validator or a more detailed mock that simulates various validation scenarios.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
scripts/build-newsroom-videos.js (2)
7-10: LGTM: Directory creation logic added.The new code block effectively ensures that the target directory exists before attempting to write the file. This prevents potential errors and improves the robustness of the script.
Consider adding error handling for the
mkdirSynccall:if (!existsSync(dir)) { try { mkdirSync(dir, { recursive: true }); } catch (err) { throw new Error(`Failed to create directory: ${err.message}`); } }This will provide more specific error information if directory creation fails.
1-10: Overall assessment: Improved robustness without affecting core functionality.The changes in this file focus on ensuring the target directory exists before writing the output file. This improvement adds robustness to the script without altering its core functionality of fetching and processing YouTube video data.
The error handling for the YouTube API interaction remains intact, maintaining the script's reliability for its primary purpose.
Consider adding a config file or environment variable for the output directory path. This would make the script more flexible and easier to configure in different environments.
tests/build-newsroom-videos.test.js (2)
18-20: LGTM: Improved error handling in cleanup.The addition of the existence check before removing the test directory is a good practice. It prevents potential errors if the directory doesn't exist.
Consider using the
fs.promisesAPI for asynchronous file system operations, which can lead to more consistent and easier-to-maintain code:const fs = require('fs').promises; afterAll(async () => { try { await fs.rm(testDir, { recursive: true, force: true }); } catch (error) { if (error.code !== 'ENOENT') { throw error; } } });This approach handles the directory removal asynchronously and catches any errors, only re-throwing if it's not a "directory not found" error.
24-26: LGTM: Improved directory handling in test setup.The addition of the existence check before creating the test directory is a good practice. It prevents unnecessary directory creation attempts and potential errors.
Consider using the
fs.promisesAPI for asynchronous file system operations:const fs = require('fs').promises; beforeEach(async () => { await fs.mkdir(testDir, { recursive: true }); fetch.mockClear(); });This approach handles the directory creation asynchronously and the
recursive: trueoption automatically creates parent directories if they don't exist, eliminating the need for an explicit existence check.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
- scripts/build-newsroom-videos.js (1 hunks)
- scripts/build-tools.js (1 hunks)
- tests/build-newsroom-videos.test.js (4 hunks)
- tests/build-tools.test.js (2 hunks)
- tests/tools/combine-tools.test.js (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- scripts/build-tools.js
- tests/build-tools.test.js
- tests/tools/combine-tools.test.js
🧰 Additional context used
🔇 Additional comments (3)
scripts/build-newsroom-videos.js (1)
1-2: LGTM: Necessary imports added for new functionality.The additional imports (
mkdirSync,existsSync, anddirname) are correctly added and align with the new directory creation logic introduced in the file.tests/build-newsroom-videos.test.js (2)
1-1: LGTM: Appropriate import added for directory existence check.The addition of
existsSyncto the imports is necessary and aligns with the new directory existence checks implemented in the test suite. This change improves the robustness of the tests.
Line range hint
1-95: Overall assessment: Good improvements with minor suggestions.The changes in this file generally improve the robustness of the test suite by adding necessary checks for directory existence. Here's a summary of the review:
- The addition of
existsSyncimport is appropriate.- The
afterAllandbeforeEachhooks now handle directory operations more safely.- There's a redundant directory check in one of the test cases that should be addressed.
Consider the suggestions for using
fs.promisesAPI for more consistent asynchronous file operations. These changes will further enhance the quality and maintainability of the test suite.
tests/build-newsroom-videos.test.js
Outdated
| if (!existsSync(testDir)) { | ||
| mkdirSync(testDir, { recursive: true }); | ||
| } | ||
|
|
There was a problem hiding this comment.
Consider removing redundant directory check.
The directory existence check and creation logic here is redundant with the one in the beforeEach hook. Unless there's a specific reason for this additional check that's not immediately apparent, consider removing it to keep the test case focused on its primary purpose.
If you decide to keep this check, please add a comment explaining why it's necessary here in addition to the beforeEach hook. Otherwise, you can remove these lines:
- if (!existsSync(testDir)) {
- mkdirSync(testDir, { recursive: 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.
| if (!existsSync(testDir)) { | |
| mkdirSync(testDir, { recursive: true }); | |
| } |
This PR adds test for combine tools script.
Summary by CodeRabbit
New Features
Bug Fixes
combineToolsfunction to catch exceptions and log validation errors.Tests
combineToolsfunction to ensure reliability and correctness.