-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
wip showcase options tracing tests #29709
wip showcase options tracing tests #29709
Conversation
@@ -41,7 +41,7 @@ | |||
"audit": "node ../../../common/scripts/rush-audit.js && rimraf node_modules package-lock.json && npm i --package-lock-only 2>&1 && npm audit", | |||
"build:test": "tsc -p . && dev-tool run bundle", | |||
"build:samples": "echo Obsolete.", | |||
"build": "npm run clean && tsc -p . && dev-tool run bundle && dev-tool run extract-api", | |||
"build": "npm run clean && tsc -p . && dev-tool run extract-api", |
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.
ignore, just speeding things up
@@ -89,7 +89,7 @@ | |||
"@azure/core-lro": "^2.5.1", | |||
"@azure/core-paging": "^1.4.0", | |||
"@azure/core-rest-pipeline": "^1.6.0", | |||
"@azure/core-tracing": "^1.0.0", | |||
"@azure/core-tracing": "1.1.3", |
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.
pin to 1.1.3, while test-utils pins to 1.1.2 - this allows me to update test-utils without patching node_modules
namespace: "Microsoft.AppConfiguration", | ||
packageName: "@azure/app-configuration", | ||
packageVersion, | ||
instrumenter: appConfigOptions.instrumenter, |
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.
Moved to client constructor so we can pass it through
let recorder: Recorder; | ||
|
||
beforeEach(async function (this: Context) { | ||
recorder = await startRecorder(this); | ||
client = createAppConfigurationClientForTests(recorder.configureClientOptions({})); | ||
fixedClient = createAppConfigurationClientForTests( | ||
recorder.configureClientOptions({ | ||
instrumenter, |
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.
this fixedClient plumbs the thing through
}); | ||
|
||
afterEach(async () => { | ||
await recorder.stop(); | ||
}); | ||
|
||
it("can trace through the various options", async function () { | ||
console.log("expected to fail with missing spans"); |
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.
To avoid dealing with recorder, I just name the tests with the exact same name, but the console log should match and we should see two pass and one fail
API change check APIView has identified API level changes in this PR and created following API reviews. |
); | ||
}); | ||
|
||
it("can trace through the various options", async function () { |
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.
This is the other option, which we can centralize of course and clean up, but the TL;DR; is
- mock in some way that you can check the span names
- check that withSpan was called N times
- check that the span names match
I like the other option better
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.
To me the mock approach is more of a true unit test, but if we're really trying to validate scenario correctness, the extra plumbing of passing the instrumenter seems fairly low overhead and feels good from a dependency injection POV.
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.
Yeah the more I look at it the more I am on the fence 😄 I like that we don't have to add anything to the public API to support these tests and I think the test coverage is sufficient - core-rest-pipeline which outputs the most important spans (the HTTP spans) doesn't use this helper today so that remains unchanged.
I think out of the two, what will help me is to sync up with @mpodwysocki and get a better understanding on which approach will play nicer with vitest and ESM. That will likely help sway one way or another...
If we decided to go this approach though, I can own updating all the packages and tests - it'll be tedious but not too hard...
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'm with @xirzec that we should test for correctness and passing through with dependency injection seems a bit nicer than replacing globals.
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.
SGTM, I created this issue to track that work #29736 as a longer term fix
76d04e6
to
a6e4e49
Compare
a6e4e49
to
3e6a540
Compare
@@ -73,14 +72,17 @@ import { | |||
transformKeyValueResponseWithStatusCode, | |||
transformSnapshotResponse, | |||
} from "./internal/helpers"; | |||
import { SyncTokens, syncTokenPolicy } from "./internal/synctokenpolicy"; | |||
import { TokenCredential, isTokenCredential } from "@azure/core-auth"; |
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 to use type
when possible for imports.
@@ -2,6 +2,7 @@ | |||
// Licensed under the MIT license. | |||
|
|||
import { | |||
Instrumenter, |
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 once again to import type
### Packages impacted by this PR @azure-tools/test-utils ### Issues associated with this PR Resolves #29736 ### Describe the problem that is addressed by this PR When @azure-tools/test-utils moves to `npm` it will no longer default to the on-disk version of core-tracing. This impacts our `supportsTracing` test helper as it no longer sets the instrumenter on the same version as the client package. Imagine this flow: <img src="https://github.com/Azure/azure-sdk-for-js/assets/753570/12d52e8e-16c1-44b3-b57d-edd31a1e4627" width=70% height=70%> In this case, test-util and app-configuration are not talking to the same "module global" instrumenter. This PR fixes this by removing core-tracing from test-utils, setting it as a peerDependency instead. All packages that test tracing also implement tracing, and as such are already depending on core-tracing. This was verified locally, but I'll need to get it out to NPM before verification can complete ### Alternatives See #29709 for a few alternatives: 1. Pass the instrumenter through 2. Use mocks Both require updates to multiple packages and/or adding public API surface which is unnecessary. We can fallback to those options if we have to, but this is a promising alternative.
Examining various options to fix tracing tests, as we discussed.
versions fe29268
Should be reviewed commit by commit