-
Notifications
You must be signed in to change notification settings - Fork 0
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
Test coverage for Xml Http Plugin #2
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: Daniel Dyla <[email protected]>
…telemetry#1197) Co-authored-by: Mayur Kale <[email protected]>
* chore: adding plugin-fetch and example * chore: investigating failing test * chore: chore fixing tests with better fetch mocking * chore: addressing comments * chore: lint * chore: addressing comments * chore: updating webpack-env * chore: fixes after update for node types * chore: addressing reviews * chore: fixes after merge * chore: updating version Co-authored-by: Mayur Kale <[email protected]> Co-authored-by: Daniel Dyla <[email protected]>
|
||
it('should NOT clear the resources', () => { | ||
assert.strictEqual( | ||
clearResourceTimingsSpy.args.length, |
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.
Are we testing if the clearResourceTimings
function was ever called or are we testing the length of the argument passed (which is what it currently appears to be testing).
If what you wish to check for is the number of times the method was invoked, you could use assert.strictEqual(clearResourceTimingsSpy.notCalled)
.
|
||
it('should NOT create any span', () => { | ||
assert.strictEqual( | ||
exportSpy.args.length, |
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.
Same as above comment.
|
||
it('should clear the resources', () => { | ||
assert.strictEqual( | ||
clearResourceTimingsSpy.args.length, |
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.
Same as above. You could use notCalled
, calledOnce
, calledTwice
to check how many times a method was called.
}); | ||
|
||
describe('when reusing the same XML Http request', () => { | ||
let reusableReq: XMLHttpRequest; //= new XMLHttpRequest(); |
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: is this a left-behind comment?
let reusableReq: XMLHttpRequest; //= new XMLHttpRequest(); | ||
const firstUrl = 'http://localhost:8090/get'; | ||
const secondUrl = 'http://localhost:8099/get'; | ||
const getDataReuseXHR = ( |
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.
Could you reuse getData
? I see that the only difference is that getDataReuseXHR
does not have the timeout
or onAbort
set.
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 added getDataReuseXHR
to call .open and .send on the same XMLHttpRequest object every time it's called, whereas in the original getData
, a new request object is created every time the function is called.
I can change getData to take in a request object and have it continue to create a new XML request every time it's currently called
}); | ||
|
||
it('should clear previous span information', () => { | ||
const span: tracing.ReadableSpan = exportSpy.args[2][0][0]; |
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.
Out of curiosity, do you know why you check exportSpy.args[2][0][0]
instead of exportSpy.args[1][0][0]
? I am assuming you are checking for the XHR with the secondUrl
.
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 know to check the arg at [2] because this test is nested inside a beforeEach (which sets up other stuff like spies as well) that sets up a preflight and initial span created in addition to the span created for this test.
Would it be better to pull out this test & the other tests that rely on the other beforeEach like I did for the unsuccessful cases?
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. Thank you for the explanation!
const attributes = span.attributes; | ||
const keys = Object.keys(attributes); | ||
|
||
assert.ok( |
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 that you added various request unsuccessful cases! The test cases look good.
I noticed that the test file became a bit lengthy and am wondering if we could maybe factor out the span attribute testing into a function and call that function instead (I am unsure if this would be a good idea since we using too many helper functions is usually discouraged in test files for easier readability, so I may ask for Eryn's opinion as well).
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.
Helper functions can be useful in tests if they don't negatively impact the readability.
It looks like enough changes in each assertion that keeping them separate is probably the better idea.
Codecov Report
@@ Coverage Diff @@
## master #2 +/- ##
=========================================
Coverage ? 94.11%
=========================================
Files ? 2
Lines ? 187
Branches ? 27
=========================================
Hits ? 176
Misses ? 11
Partials ? 0 |
const attributes = span.attributes; | ||
const keys = Object.keys(attributes); | ||
|
||
assert.ok( |
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.
Helper functions can be useful in tests if they don't negatively impact the readability.
It looks like enough changes in each assertion that keeping them separate is probably the better idea.
let rootSpan: api.Span; | ||
let spyEntries: any; | ||
const url = `${window.location.origin}/xml-http-request.js`; | ||
const url = 'http://localhost:8090/xml-http-request.js'; |
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.
Is there any danger with coding this to a specific host/port. For example, it is possible that they could be changed by configuration somewhere?
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.
The link doesn't point to anything in the test suite, it ends up getting called with a FakeXMLHttpRequest so I don't think it would be affected
The tests written for the fetch api do this hard coding as well so I think it should be safe: https://github.com/open-telemetry/opentelemetry-js/blob/a2d1964b16018837c009f6f75351a41a00a66650/packages/opentelemetry-plugin-fetch/test/fetch.test.ts#L100
…1204) Co-authored-by: Mayur Kale <[email protected]>
* chore: fixing zone from which to fork a new zone * chore: adding tests for creating zone Co-authored-by: Mayur Kale <[email protected]>
Signed-off-by: Tina Gao <[email protected]>
added test for when request url is an ignored url from plugin config
fix header propagation tests that were affected by added a preflight span
Added tests for clearTimingResources setting in the plugin's config for the default behaviour when unspecified (false) and for explicitly setting to true.
a8ef57a
to
0ca3f9f
Compare
Co-authored-by: Daniel Dyla <[email protected]> Co-authored-by: Mayur Kale <[email protected]>
Co-authored-by: Daniel Dyla <[email protected]>
Co-authored-by: Mayur Kale <[email protected]>
Which problem is this PR solving?
TODO: reference issue properly when changing base to main repo
Short description of the changes