Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: onboard a utility for getting the test data for manual testing #3092

Closed
wants to merge 2 commits into from

Conversation

utsabc
Copy link
Member

@utsabc utsabc commented Feb 14, 2024

What are the changes introduced in this PR?

Added utility to get test data for manual testing

What is the related Linear task?

Resolves INT-1567

Developer checklist

  • My code follows the style guidelines of this project

  • No breaking changes are being introduced.

  • All related docs linked with the PR?

  • All changes manually tested?

  • Any documentation changes needed with this change?

  • Is the PR limited to 10 file changes?

  • Is the PR limited to one linear task?

  • Are relevant unit and component test-cases added?

Reviewer checklist

  • Is the type of change in the PR title appropriate as per the changes?

  • Verified that there are no credentials or confidential data exposed with the changes.

Summary by CodeRabbit

  • New Features
    • Introduced a new option in integration tests to specify the mode of operation, enhancing test data handling.
  • Chores
    • Updated .gitignore to exclude temporary files, improving file management.

@utsabc utsabc requested review from sivashanmukh and a team as code owners February 14, 2024 14:58
Copy link
Contributor

coderabbitai bot commented Feb 14, 2024

Important

Auto Review Skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository.

To trigger a single review, invoke the @coderabbitai review command.

Walkthrough

The recent update introduces a more flexible testing environment by allowing the selection of operation modes and improving file management. Specifically, it adds a new command-line option to specify the operation mode for integration tests, enabling conditional logic for test data handling. Additionally, the update enhances the project's organization by ignoring temporary files in the .gitignore file, ensuring a cleaner workspace.

Changes

File(s) Change Summary
.gitignore Updated to ignore the temp/ directory, helping in managing temporary files more effectively.
.../component.test.ts Added -m, --mode <string> option for specifying operation mode. Introduced conditional logic for handling test data based on the selected mode (passive or active), affecting whether test data is printed to a file or specific test handlers are executed.

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?

Share

Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit-tests for this file.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit tests for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository from git and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit tests.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

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 as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

@utsabc
Copy link
Member Author

utsabc commented Feb 14, 2024

@coderabbitai revie

@devops-github-rudderstack
Copy link
Contributor

Copy link
Contributor

coderabbitai bot commented Feb 14, 2024

@utsabc: It seems like you're requesting a review of the pull request. I'll proceed with reviewing the code changes. Please note that I cannot directly access external URLs, such as the test report you mentioned, but I will do my best to provide a thorough review based on the code changes. If there's anything specific you'd like me to focus on, please let me know.

Action performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link

codecov bot commented Feb 14, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (6a364fb) 87.21% compared to head (50794c6) 87.21%.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #3092   +/-   ##
========================================
  Coverage    87.21%   87.21%           
========================================
  Files          537      537           
  Lines        29243    29243           
  Branches      6962     6962           
========================================
  Hits         25503    25503           
  Misses        3393     3393           
  Partials       347      347           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

test/integrations/component.test.ts Outdated Show resolved Hide resolved
test/integrations/component.test.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 6

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 6a364fb and 535b378.
Files selected for processing (2)
  • .gitignore (1 hunks)
  • test/integrations/component.test.ts (3 hunks)
Files skipped from review due to trivial changes (1)
  • .gitignore

test/integrations/component.test.ts Outdated Show resolved Hide resolved
@@ -98,6 +99,7 @@
registerAxiosMocks(allAxiosRequests);
}

const mode = opts.mode || 'active';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default value for mode is set here, but it could be more efficiently handled directly in the command option definition to ensure opts.mode always has a valid value.

Consider moving the default value assignment to the command option definition to simplify the code and avoid redundant checks.

Comment on lines 228 to 262
if (mode === 'passive') {
// print the test data
const result: any = [];
testData.forEach((tcData) => {
let events;
switch (tcData.feature) {
case tags.FEATURES.PROCESSOR:
events = tcData.input.request.body;
break;
case tags.MODULES.SOURCE:
await sourceTestHandler(tcData);
case tags.FEATURES.BATCH:
events = tcData.input.request.body.input;
break;
default:
console.log('Invalid module');
// Intentionally fail the test case
expect(true).toEqual(false);
case tags.FEATURES.ROUTER:
events = tcData.input.request.body.input;
break;
}

events.map((event) => {
result.push(event.message);
});
});
});

it('data generated successfully', () => {
// write the data to a file

// create directory if not exists
const dir = join(__dirname, '../../temp');
if (!require('fs').existsSync(dir)) {
require('fs').mkdirSync(dir);
}
appendFileSync(join(__dirname, '../../temp/test_data.json'), JSON.stringify(result, null, 2));
console.log('Data generated successfully at temp/test_data.json');
expect(true).toEqual(true); // Intentionally pass the test case
});
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The passive mode block generates test data and writes it to a file. However, there's a potential issue with the handling of the events variable. It's declared inside a switch statement and used outside of it, which could lead to reference errors if none of the cases match.

Ensure events is initialized before the switch statement to avoid reference errors. Also, consider handling the case where tcData.feature does not match any case, to avoid pushing undefined into result.

Comment on lines 251 to 261
// write the data to a file

// create directory if not exists
const dir = join(__dirname, '../../temp');
if (!require('fs').existsSync(dir)) {
require('fs').mkdirSync(dir);
}
appendFileSync(join(__dirname, '../../temp/test_data.json'), JSON.stringify(result, null, 2));
console.log('Data generated successfully at temp/test_data.json');
expect(true).toEqual(true); // Intentionally pass the test case
});
Copy link
Contributor

@coderabbitai coderabbitai bot Feb 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Writing test data to a file is done within a test case. This approach mixes test data generation with test execution, which might not be ideal for readability and maintainability.

Consider separating test data generation from test assertions. Use a separate function or script for generating and writing test data to ensure clear separation of concerns.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we write some other util for generation based on this comment? @utsabc

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Comment on lines 255 to 256
if (!require('fs').existsSync(dir)) {
require('fs').mkdirSync(dir);
Copy link
Contributor

@coderabbitai coderabbitai bot Feb 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using require('fs') directly within the test case for checking directory existence and creating a directory. This approach is not efficient as it does not leverage asynchronous file system operations and repeats the require('fs') call.

Extract fs module usage to the top of the file and use asynchronous versions of existsSync and mkdirSync to improve efficiency and code readability.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was talking about this in my earlier comment

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@koladilip: I understand there might have been a misunderstanding or a missed context regarding the use of require('fs') within the test case. Could you please provide more details or clarify the concern you mentioned in your earlier comment? I'm here to help and ensure the review is as accurate and helpful as possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

basically, I was also saying that @utsabc should put existsSync and mkdirSync in top imports

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Comment on lines 263 to 282
describe(`${testData[0].name} ${testData[0].module}`, () => {
test.each(testData)('$feature -> $description', async (tcData) => {
tcData?.mockFns?.(mockAdapter);

switch (tcData.module) {
case tags.MODULES.DESTINATION:
await destinationTestHandler(tcData);
break;
case tags.MODULES.SOURCE:
await sourceTestHandler(tcData);
break;
default:
console.log('Invalid module');
// Intentionally fail the test case
expect(true).toEqual(false);
break;
}
});
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The active mode block executes test handlers based on the module type. However, there's a lack of error handling for asynchronous operations within the test cases.

Add try-catch blocks around asynchronous operations to handle potential errors gracefully and provide meaningful error messages for test failures.

@utsabc utsabc requested a review from koladilip February 15, 2024 05:24
@devops-github-rudderstack
Copy link
Contributor

Copy link

Quality Gate Passed Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@utsabc utsabc closed this Feb 21, 2024
@utsabc utsabc deleted the chore.script-fr-test-data branch February 21, 2024 04:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants