Get rid of axios dependency in the Upgrade Assistant tests.#127122
Get rid of axios dependency in the Upgrade Assistant tests.#127122azasypkin merged 3 commits intoelastic:mainfrom
axios dependency in the Upgrade Assistant tests.#127122Conversation
sabarasaba
left a comment
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
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.
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: |
sabarasaba
left a comment
There was a problem hiding this comment.
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 thisaxiosusage in the tests (axiosjust 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
HttpSetupmock instead ofaxios+sinonserver 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