Skip to content
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

Closed

Conversation

maorleger
Copy link
Member

@maorleger maorleger commented May 15, 2024

Examining various options to fix tracing tests, as we discussed.

  • Plumber work to get the correct instrumenter regardless of core-tracing
    versions fe29268
  • Mock createTracingClient and assert on mock 3e6a540

Should be reviewed commit by commit

@github-actions github-actions bot added App Configuration Azure.ApplicationModel.Configuration Azure.Core test-utils Label for the issues related to the @azure/test-utils package labels May 15, 2024
@@ -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",
Copy link
Member Author

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",
Copy link
Member Author

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,
Copy link
Member Author

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,
Copy link
Member Author

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");
Copy link
Member Author

@maorleger maorleger May 15, 2024

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

@azure-sdk
Copy link
Collaborator

azure-sdk commented May 15, 2024

API change check

APIView has identified API level changes in this PR and created following API reviews.

@azure/core-tracing

);
});

it("can trace through the various options", async function () {
Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

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...

Copy link
Member

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.

Copy link
Member Author

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

@maorleger maorleger force-pushed the wip-showcase-options-tracing-tests branch 2 times, most recently from 76d04e6 to a6e4e49 Compare May 15, 2024 22:13
@maorleger maorleger force-pushed the wip-showcase-options-tracing-tests branch from a6e4e49 to 3e6a540 Compare May 15, 2024 22:21
@@ -73,14 +72,17 @@ import {
transformKeyValueResponseWithStatusCode,
transformSnapshotResponse,
} from "./internal/helpers";
import { SyncTokens, syncTokenPolicy } from "./internal/synctokenpolicy";
import { TokenCredential, isTokenCredential } from "@azure/core-auth";
Copy link
Member

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,
Copy link
Member

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

@maorleger maorleger closed this May 17, 2024
maorleger added a commit that referenced this pull request May 23, 2024
### 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
App Configuration Azure.ApplicationModel.Configuration Azure.Core test-utils Label for the issues related to the @azure/test-utils package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants