-
Notifications
You must be signed in to change notification settings - Fork 8.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
Get rid of axios
dependency in the Upgrade Assistant tests.
#127122
Get rid of axios
dependency in the Upgrade Assistant tests.
#127122
Conversation
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.
Thanks for working on this @azasypkin! Most changes lgtm, though I left some questions/observations that I would like to get your opinion on 🎸
httpRequestsMockHelpers.setLoadDeprecationLoggingResponse(getLoggingResponse(true)); | ||
testBed = await setupESDeprecationLogsPage(); | ||
mockEnvironment = setupEnvironment(); | ||
mockEnvironment.httpRequestsMockHelpers.setLoadDeprecationLoggingResponse( |
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 do you think of destructing httpRequestsMockHelpers
from mockEnvironment
? I think that will reduce the noise of the diff and also make things easier to follow since the changes will be scoped to the setup of the test rather the implementation of each.
I think this change can be applied throughout most of the test files in this PR.
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.
Yep, good point, let me do that!
{ 'Content-Type': 'application/json' }, | ||
JSON.stringify(body), | ||
]); | ||
const mockResponse = (method: HttpMethod, path: string, response?: unknown, error?: unknown) => { |
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.
Love it! But was wondering if we should perhaps move all of this to a shared place (perhaps kbn-test
) from which we could re-use this in other apps also? I think would also be cool if we could optionally specify headers too!
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 see your point, but the approach you use in UA and that was copied to few other plugins (additional abstraction over existing Core's mocks) is more like an exception and not something we (Platform) recommend. It's fine for a simple use case like you have, but if you need to customize response behavior (e.g. reply with different mock response based on parameters etc.) it becomes harder than using the Core's mock directly and also it's a bit harder to follow for people outside of the team.
So I'd rather localize this approach only inside plugins that opted to use it for now, until we have enough evidence that it can be useful for the majority of the plugins.
What do you think?
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.
Makes sense 👍🏼 , I think most of the platform-management apps use this pattern but let's keep an eye open for the other kibana apps and see if this is something more teams could benefit from.
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.
Yep, sounds good 👍
expect(server.requests.length).toBe(totalRequests + 4); | ||
expect(server.requests[server.requests.length - 4].url).toBe( | ||
`${API_BASE_PATH}/es_deprecations` | ||
expect(mockEnvironment.httpSetup.get).toHaveBeenCalledWith( |
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.
If we are to refactor out mockResponse
into kbn-test
I think would be nice to have some sort of mechanism to access an array of requests made like what sinnon provides, given that you can choose what to match against rather than having to have an ordered list of expect get toHaveBeenCalledWith
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
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.
latest lgtm, thanks @azasypkin!
Thanks for the review @sabarasaba ! |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
…127122) (#127716) * Get rid of `axios` dependency in the Upgrade Assistant tests. (#127122) (cherry picked from commit 53420d8) # Conflicts: # x-pack/plugins/upgrade_assistant/__jest__/client_integration/es_deprecation_logs/es_deprecation_logs.helpers.ts # x-pack/plugins/upgrade_assistant/__jest__/client_integration/es_deprecations/es_deprecations.helpers.ts # x-pack/plugins/upgrade_assistant/__jest__/client_integration/helpers/setup_environment.tsx # x-pack/plugins/upgrade_assistant/__jest__/client_integration/kibana_deprecations/kibana_deprecations.helpers.ts # x-pack/plugins/upgrade_assistant/__jest__/client_integration/overview/overview.helpers.ts * Fix formatting.
@azasypkin FYI I reverted this at 7b86f00 due to a conflict with #126693 in main. It looks like a fix is in progress at #127779 |
Ugh, sorry about that. The fix won't work without the main PR - I'll re-create it including the changes from #127779 |
Thanks @azasypkin! I'll go ahead and close my pr then, ping me when you have this other PR open and I can have a look 👍🏼 |
Thanks, will do! |
…elastic#127122)" This reverts commit 53420d8.
Summary
In #111655 (comment) we're trying to upgrade
axios
, but are blocked because of thisaxios
usage in the tests (axios
just happened to have methods signature similar toHttpSetup
, but it's technically incorrect and quite fragile):In this PR I switched Upgrade Assistant tests to use
HttpSetup
mock instead ofaxios
+sinon
server mock preserving test helpers shape as much as possible. Feel free to scratch this PR if you have a better approach in mind!Re-merged after revert via: #127784