-
Notifications
You must be signed in to change notification settings - Fork 898
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
Added UTs for Saved queries new UI #8798
base: main
Are you sure you want to change the base?
Added UTs for Saved queries new UI #8798
Conversation
Signed-off-by: Riya Saxena <riysaxen@amazon.com>
Signed-off-by: Riya Saxena <riysaxen@amazon.com>
Signed-off-by: Riya Saxena <riysaxen@amazon.com>
ℹ️ Manual Changeset Creation ReminderPlease ensure manual commit for changeset file 8798.yml under folder changelogs/fragments to complete this PR. If you want to use the available OpenSearch Changeset Bot App to avoid manual creation of changeset file you can install it in your forked repository following this link. For more information about formatting of changeset files, please visit OpenSearch Auto Changeset and Release Notes Tool. |
❌ Changeset File Not Added YetPlease ensure manual commit for changeset file 8798.yml under folder changelogs/fragments to complete this PR. File still missing. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8798 +/- ##
==========================================
+ Coverage 60.78% 60.83% +0.05%
==========================================
Files 3798 3798
Lines 90701 90701
Branches 14284 14284
==========================================
+ Hits 55135 55181 +46
+ Misses 32067 32021 -46
Partials 3499 3499
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Signed-off-by: Riya Saxena <riysaxen@amazon.com>
Can you add the changeset file and check codecov, failing. |
Callouts:
|
Signed-off-by: Riya Saxena <riysaxen@amazon.com>
yes, i observed UTs failing for saved queries, revised the Pr to fix them |
@@ -51,7 +51,7 @@ export class AutocompleteService { | |||
private getValueSuggestions?: ValueSuggestionsGetFn; | |||
|
|||
private addQuerySuggestionProvider = (language: string, provider: QuerySuggestionGetFn): void => { | |||
if (language && provider && this.autocompleteConfig.querySuggestions.enabled) { | |||
if (language && provider && this.autocompleteConfig?.querySuggestions.enabled) { |
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.
what led us to using optional chaining if we're not exercising this through testing?
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.
seems like we don't have any coverage on autocomplete_service.ts,
While writing unit tests for src/plugins/data/public/plugin, we initialize all the services, including
this.searchService = new SearchService(initializerContext);
this.uiService = new UiService(initializerContext);
this.queryService = new QueryService();
this.fieldFormatsService = new FieldFormatsService();
this.autocomplete = new AutocompleteService(initializerContext);
The optional chaining ensures that if autocompleteConfig or querySuggestions is not defined (i.e., null or undefined), it won’t cause a runtime error when trying to access enabled.
In short, while the autocomplete_service.ts might not have direct test coverage, the use of optional chaining here is a safety feature that prevents errors when properties or objects are not available during execution. If the service were better covered in the tests, we’d be able to verify if this behavior is actually necessary or if there is a more predictable initialization pattern that could be tested directly.
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.
Did you add it unprompted as a safety measure, or because you saw it failing in some cases? I am curious about the other cases as well, but using this as an example.
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.
but why would querySuggestions be undefined? it's enforced by type and config-schema which provides a default value
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.
yes, i added it because the UTs were failing with Cannot read property of undefined
for the following lines
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 would prefer for the UTs to be fixed to call the stack correctly. Do you know which ones were failing? Not that this change is unsafe to have... just that those tests that are not creating the proper context could be missing stuff.
if (setting === UI_SETTINGS.QUERY_ENHANCEMENTS_ENABLED) { | ||
return true; | ||
} | ||
return false; |
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.
nit: return setting === UI_SETTINGS.QUERY_ENHANCEMENTS_ENABLED;
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.
addressed
Signed-off-by: Riya Saxena <riysaxen@amazon.com>
describe('#DataPublicPlugin setup', () => { | ||
let coreSetup: any; | ||
let coreStart: any; | ||
let plugin; |
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.
nit. avoid any if possible
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.
addressed
@@ -183,7 +183,7 @@ export class DataPublicPlugin | |||
|
|||
const useNewSavedQueriesUI = | |||
core.uiSettings.get(UI_SETTINGS.QUERY_ENHANCEMENTS_ENABLED) && | |||
this.config.savedQueriesNewUI.enabled; | |||
this.config.savedQueriesNewUI?.enabled; |
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.
why this change?
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.
these files aren't covered by any UTs, so when writing tests for data/public/plugin since all these services are initialized, i was getting the error Cannot read property of undefined
for all these lies [ref: https://github.com//pull/8798#discussion_r1828538194]
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.
Ideally, we're just mocking things to not have to change the source code. It's mainly problematic if we fail in an unexpected way (there are times where failing fast and throwing is preferable to going down a code path that we didn't intend, and patch coverage % points to that being a concern here), but its usages in this CR don't seem that problematic, so I'm fine approving. Please do review however, and if the optional chaining presents a risk, let's fix in tests vs source.
@@ -51,7 +51,7 @@ export class AutocompleteService { | |||
private getValueSuggestions?: ValueSuggestionsGetFn; | |||
|
|||
private addQuerySuggestionProvider = (language: string, provider: QuerySuggestionGetFn): void => { | |||
if (language && provider && this.autocompleteConfig.querySuggestions.enabled) { | |||
if (language && provider && this.autocompleteConfig?.querySuggestions.enabled) { |
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.
but why would querySuggestions be undefined? it's enforced by type and config-schema which provides a default value
Signed-off-by: Riya Saxena <riysaxen@amazon.com>
@@ -183,7 +183,7 @@ export class DataPublicPlugin | |||
|
|||
const useNewSavedQueriesUI = | |||
core.uiSettings.get(UI_SETTINGS.QUERY_ENHANCEMENTS_ENABLED) && | |||
this.config.savedQueriesNewUI.enabled; | |||
this.config.savedQueriesNewUI?.enabled; |
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.
Ideally, we're just mocking things to not have to change the source code. It's mainly problematic if we fail in an unexpected way (there are times where failing fast and throwing is preferable to going down a code path that we didn't intend, and patch coverage % points to that being a concern here), but its usages in this CR don't seem that problematic, so I'm fine approving. Please do review however, and if the optional chaining presents a risk, let's fix in tests vs source.
Description
Created UTs for Saved queries new UI(#8469)
Issues Resolved
Screenshot
Testing the changes
Changelog
Check List
yarn test:jest
yarn test:jest_integration