-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
{ASI} :- Error message to be cached for grid data storage component #26502
{ASI} :- Error message to be cached for grid data storage component #26502
Conversation
Hi @konarshankar07. Thank you for your contribution
For more details, please, review the Magento Contributor Guide documentation. |
@konarshankar07 thanks for opening the pull request! there was a jasmine test created for this method, could you include it with this pull request as well? |
@sivaschenko Yes, I'm going to add those jasmine test with this PR but I think we should cover other methods with the jasmine test for data-storage so I'm working on it |
Waiting for magento/adobe-stock-integration#884 to be merged in order to merge this one |
@diazwatson ... Actually its opposite to your comment. We need to merge this PR in order to merge ASI PR |
Thanks for clarifying @konarshankar07 |
@diazwatson... Code Review for jasmine test cause I'm very new to the jasmine test so I might have missed any test or needs an improvement |
Maybe @filmaj can help? 😅 |
@diazwatson ... Yes @sivaschenko or @filmaj both can review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done on the tests! I left a couple of comments around labeling. Wording is important 😄
expect(model.getRequest).toHaveBeenCalled(); | ||
}); | ||
|
||
it('Return "getRequestData" method', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I think we should try to do is provide good test names. This may seem like a silly recommendation, but as a first-time contributor to the project, one of the first things I do to familiarize myself with the project is read the tests! While I understand what the intention behind this test is, it only became clear to me after reading the data-storage getData
method.
I would suggest naming the test something like "it returns cached request data if a cached request exists and no refresh option is provided". In this way, the name of the test alone is enough to explain to me some key functionality of this module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd agree that test names should be more detailed to differentiate test between each other, however, I wouldn't make them too long. I don't think test results can be accessed without reading the code (by name only).
expect(model.getRequestData).toHaveBeenCalled(); | ||
}); | ||
|
||
it('Return "requestData" method', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Along the same lines as my last comment, let's qualify the test name further. How does it differentiate from the previous test? having multiple tests with the same name is not recommended - that can be quite confusing. Wording matters! Remember that tests are a tool to help us, the developers, be productive and guide us. Spending the extra few minutes to properly comment, document and name things goes a long way to making the code maintainable long term.
Thanks @filmaj for reviewing the pull request and will work on the your suggestions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @konarshankar07 thank you for the pull request! The implementation looks fine, the only comments I have are addressed to the test:
- I don't think that abstract checks like
toBeDefined
,toBeTruthy
,expect(type).toEqual
provide enough information to assume that the method is working correctly - I'd limit the tests to verifying the actual return of the method depending on arguments
it('Check returned value if method called with argument', function () { | ||
var ids = [1,2,3]; | ||
|
||
expect(model.getByIds(ids)).toBeDefined(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think toBeDefined
is a specific enough case to be checked separately. I'd focus on testing the concrete return values instead
dataScope: 'magento' | ||
}); | ||
|
||
it('check for defined', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think check for defined
and check method type
are necessary? If the function is not declared the following tests will fail anyway and it wouldn't be hard to identify the problem.
expect(model.initConfig()).toBeDefined(); | ||
}); | ||
|
||
it('Check returned value type if method called without arguments', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think Check for defined
, Check method type
, Check returned value if method called without arguments
and Check returned value type if method called without arguments
are necessary
expect(model.getByIds(ids)).toEqual(false); | ||
}); | ||
|
||
it('Return array if "getByIds" has been called', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be good to test the case when ids
parameter contains both existing and non-existing ids
} | ||
}); | ||
|
||
expect(typeof model.getByIds(ids)).toEqual('object'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd check for the specific object
var ids = [1,2,3], | ||
type = typeof model.getIds(ids); | ||
|
||
expect(type).toEqual('object'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd check for specific return
expect(typeof model.getIds).toEqual('function'); | ||
}); | ||
|
||
it('check returned value if method called with argument', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's beneficial to test booth return type and return value - only one check for return value would be enough.
It'd be better to check the case when no arguments are passed to getIds
method instead.
it('check returned value if method called with argument', function () { | ||
var ids = [1,2,3]; | ||
|
||
expect(model.getIds(ids)).toBeDefined(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
toBeDefined
is not actually a check for value, it would be good to verify the actual returned value
model.cacheRequest(data, params); | ||
expect(typeof model._requests).toEqual('object'); | ||
expect(model.getIds).toHaveBeenCalled(); | ||
expect(model.getRequest(params)).toEqual(request); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here we need to also test model._requests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to test it through getRequest
as _requests
property is a detail of internal implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, _requests
array pushed functionality is added in the cacheRequest
method so I thought that we need to cover in the cacheRequest
functionality
Hi @sivaschenko, thank you for the review. |
Hi @konarshankar07, thank you for your contribution! |
Description (*)
This PR is part of the ASI issue in which error message is not cached when user try to apply filter
Fixed Issues (if relevant)
Manual testing scenarios (*)
Please check magento/adobe-stock-integration#884
Questions or comments
Contribution checklist (*)