-
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
[Ingest pipelines] Tests for pipeline debugging enhancement #75606
[Ingest pipelines] Tests for pipeline debugging enhancement #75606
Conversation
53604c8
to
a86dd6f
Compare
206de7c
to
a50d115
Compare
@elasticmachine merge upstream |
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
cc @cuff-links |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
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.
Great work @alisonelizabeth ! Very well written tests. I left a comment about mocking uuid
, not sure if that would simplify things of make it more complex. I let you decide.
// Initialize mock services | ||
uiMetricService.setup(usageCollectionPluginMock.createSetupContract()); | ||
// @ts-ignore | ||
apiService.setup(mockHttpClient, uiMetricService); |
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 is strange to have this setup
call and the one above inside the initHttpRequests
as it is not related.
In other places we have a setupEnvironement()
where we setup the services and call the initHttpRequests
. Do you mind keeping it consistent?
<KibanaContextProvider services={appServices}> | ||
<ProcessorsEditorContextProvider {...props}> | ||
<TestPipelineActions /> | ||
<ProcessorsEditor /> <GlobalOnFailureProcessorsEditor /> |
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: maybe the <GlobalOnFailureProcessorsEditor />
on the next line for readability?
// this is generated dynamically and not something we can stub. | ||
// As a workaround, the value is added as a data attribute in the UI | ||
// and we retrieve it to generate the mocked output. | ||
const addProcessorTagtoMockOutput = (output: VerboseTestOutput) => { |
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 guess that another way would have been to mock the v4()
method of the uuid
package and return a sequential id. So if there are 5 processors, their id would be 0, 1, 2, 3, 4.
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.
Good point. I'm going to leave this as-is for now, but will consider refactoring it as I add more tests.
💚 Build SucceededBuild metricsasync chunks size
History
To update your PR or re-run it, just comment with: |
This PR adds test coverage for the work implemented via #74964.