[instrumentation-fetch] refactor fetch() tests for clarity, type safety and realism #5268

chancancode · 2024-12-14T02:39:56Z

Which problem is this PR solving?

Refactor fetch() tests for improved clearity, type safety and realism (relative to the real-world fetch behavior).

I would like to propose something for #4888 to start a discussion, but in doing so I find that the current tests are quite confusing to work with, so I split out these refactors to the tests as a separate PR/proposal.

I think this represents a significant enough improvements to the tests that it makes sense as a PR, but ~~I may something else that I want to try/propose next week~~ in the longer term, I am also proposing that we further refactor these tests in #5282.

Short description of the changes

See the inline commits on the PR.

Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update
Internal refactor

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

npm run lint
npm run test:browser

Checklist:

Followed the style guidelines of this project
Unit tests have been ~~added~~ updated
Documentation has been updated

Refactor `fetch()` tests for improved clearity, type safety and realism (relative to the real-world `fetch` behavior). See the inline comments on PR open-telemetry#5268 for a detailed explaination of the changes.

chancancode · 2024-12-14T02:44:35Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

@@ -176,7 +176,7 @@ function testForCorrectEvents(

 describe('fetch', () => {
  let contextManager: ZoneContextManager;
-  let lastResponse: any | undefined;
+  let lastResponse: Response | undefined;


This changes more than the type! Despite the name, this variable previously wasn't storing the Response object of the last fetch() request. It stores something that is kind of the parsed response body (~= await response.json()) but also with some additional bespoke processing/normalization that didn't turn out to be necessary.

This changes things so lastResponse actually stores the Response object from the last fetch() request made in the test. Any test that cares about the response body can call await lastResponse.json() in the test itself and do what it needs to do there.

chancancode · 2024-12-14T02:46:44Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

@@ -210,12 +210,21 @@ describe('fetch', () => {
    sinon.stub(core.otperformance, 'now').callsFake(() => fakeNow);

    function fakeFetch(input: RequestInfo | Request, init: RequestInit = {}) {
+      // Once upon a time, there was a bug (#2411), causing a `Request` object
+      // to be incorrectly passed to `fetch()` as the second argument
+      assert.ok(!(init instanceof Request));


This is a replacement for the init instanceof Request branch below. We don't have this bug anymore, but this assertion will catch it if it regress, and instantly fail all the tests (synchronously).

chancancode · 2024-12-14T02:49:35Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

-        const response: any = {
-          args: {},
-          url: fileUrl,
-        };


This variable is really the "default response body", but it also serves a double-duty as the ResponseInit (second argument to new Response(), which is very confusing. I separated those into appropriately named separate variables.

To be clear, no tests actually cares that the mock "server response body" has the status in it.

chancancode · 2024-12-14T02:51:04Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

+
+        // This is the default response body expected by the few tests that cares
+        let responseBody = JSON.stringify({
+          isServerResponse: true,


args: {} in the diff is only used by a single test, and all it does with it is assert.deepEquals(parsedResponseBody.args, {}). Maybe it used to do more, but I inferred that these days the only purpose it serves is "did I get the mock response I expected", and so I replaced that with this field.

chancancode · 2024-12-14T02:53:14Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

-          // Passing request as 2nd argument causes missing body bug (#2411)
-          response.status = 400;
-          response.statusText = 'Bad Request (Request object as 2nd argument)';
-          reject(new window.Response(JSON.stringify(response), response));


This branch was replaced entirely. Note that:

It is testing for the bug in fix(instrumentation-fetch): fetch(string, Request) silently drops request body #2411 which has now be fixed, so this branch is never exercised in practice.

To avoid a regression, I replaced the spirit of this with the assert.ok at the top.

This behavior is misleading and in correct – the real fetch() never reject() the fetch promise with a response. Even when the server returns an HTTP error (response.ok === false), the promise is still resolved.

In any case, this branch is not needed anymore.

chancancode · 2024-12-14T02:55:31Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

        }
+
+        resolve(new window.Response(responseBody, responseInit));


We now always resolve, as the real fetch() would. The 404 branch is also never exercised in the tests (as evident by the fact that I changed it from resolve() to reject() and nothing broke). As mentioned above, rejecting with a response is never correct.

If we are rejecting here because it's an internal assertion that indicating some test is set up wrong, I'd rather see this reject with an regular Error, or just throw synchronously at the top.

chancancode · 2024-12-14T02:57:33Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

-          Object.keys(lastResponse.headers).forEach(key => {
-            headers[key.toLowerCase()] = lastResponse.headers[key];
-          });
-          lastResponse.headers = headers;


This is the convoluted normalization that didn't turn out to be needed (other than removing this part, most of the diff is just indentation change from removing the now-unecessary try/catch.

As far as I can tell, (other than the previously unfortunate variable naming) all this would do is to normalize the request headers into lower case. However, nothing broke when I stopped doing this, so evidently the two tests that cares don't actually need this.

chancancode · 2024-12-14T02:59:00Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

      assert.strictEqual(
-        lastResponse.headers[X_B3_TRACE_ID],
+        request.headers[X_B3_TRACE_ID],


The previously badly named variable made this very confusing, but this is actually asserting that we made the request with the correct headers. Specifically that when the URL is not ignored, the instrumentation code will add these additional headers (which then gets put into the mock server response).

chancancode · 2024-12-14T03:01:13Z

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

-          assert.fail(response.statusText);
-        }
-      );
-    });


This test was added for #2411. It is basically testing that nothing breaks when passing a Request object into fetch works. However, that pattern is now ubiquitously used in numerous other tests (e.g. see around L550), so I'm not sure this is still necessary anymore. Also as mentioned about, this test is not very realistically written, as the real fetch() would never reject() with a Response like this.

codecov · 2024-12-14T06:04:26Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.62%. Comparing base (90afa28) to head (5ee5d8f).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5268   +/-   ##
=======================================
  Coverage   94.62%   94.62%           
=======================================
  Files         323      323           
  Lines        8068     8068           
  Branches     1637     1637           
=======================================
  Hits         7634     7634           
  Misses        434      434

Refactor `fetch()` tests for improved clearity, type safety and realism (relative to the real-world `fetch` behavior). See the inline comments on PR open-telemetry#5268 for a detailed explaination of the changes.

chancancode · 2024-12-18T19:48:53Z

rebased and retargeted

pichlermarc

This looks great, thank you for cleaning up the tests here. 🙌

I have to admit that I lack a lot of context on the @opentelemetry/instrumenation-fetch and @opentelemetry/instrumenation-xhr packages as they pre-date my time on the project, so the comments you provided were a immensely helpful in figuring out what's going on. Reviewing and having to gather context would've taken me at lot longer if they had not been there.

pichlermarc · 2024-12-20T09:50:01Z

Ah, looks like there's some conflict somewhere (I can't resolve due to maintainer edits being off).

cc @open-telemetry/javascript-approvers if you see the conflicts resolved while I'm ooo please give it another quick look merge this in, thanks 🙂

CHANGELOG.md

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts

Refactor `fetch()` tests for improved clearity, type safety and realism (relative to the real-world `fetch` behavior). See the inline comments on PR open-telemetry#5268 for a detailed explaination of the changes.

chancancode · 2024-12-20T17:32:33Z

Removed the CHANGELOG entry (need a Skip Changelog label now) thus the conflict

Refactor `fetch()` tests for improved clearity, type safety and realism (relative to the real-world `fetch` behavior). See the inline comments on PR open-telemetry#5268 for a detailed explaination of the changes.

chancancode requested a review from a team as a code owner December 14, 2024 02:39

chancancode force-pushed the refactor-fetch-test branch from 1b5ad66 to e188496 Compare December 14, 2024 02:41

chancancode commented Dec 14, 2024

View reviewed changes

This was referenced Dec 18, 2024

feat(instrumentation-fetch)! Passthrough original request to applyCustomAttributes #5281

Open

[instrumentation-fetch] [Research/Discussion] Use msw for fetch (and XHR) instrumentation tests #5282

Open

chancancode force-pushed the refactor-fetch-test branch from e188496 to e279803 Compare December 18, 2024 19:48

chancancode changed the base branch from next to main December 18, 2024 19:48

pichlermarc approved these changes Dec 19, 2024

View reviewed changes

pichlermarc enabled auto-merge December 20, 2024 08:33

pichlermarc disabled auto-merge December 20, 2024 09:47

maryliag reviewed Dec 20, 2024

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

maryliag reviewed Dec 20, 2024

View reviewed changes

experimental/packages/opentelemetry-instrumentation-fetch/test/fetch.test.ts Outdated Show resolved Hide resolved

chancancode force-pushed the refactor-fetch-test branch from 7b0494c to d6d4424 Compare December 20, 2024 17:31

[instrumentation-fetch] refactor fetch tests for clearity/safety

5ee5d8f

Refactor `fetch()` tests for improved clearity, type safety and realism (relative to the real-world `fetch` behavior). See the inline comments on PR open-telemetry#5268 for a detailed explaination of the changes.

chancancode force-pushed the refactor-fetch-test branch from d6d4424 to 5ee5d8f Compare December 20, 2024 17:33

maryliag added the Skip Changelog label Dec 20, 2024

maryliag approved these changes Jan 6, 2025

View reviewed changes

pichlermarc added this pull request to the merge queue Jan 7, 2025

Merged via the queue into open-telemetry:main with commit 9c46e8f Jan 7, 2025
18 of 19 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[instrumentation-fetch] refactor fetch() tests for clarity, type safety and realism #5268

[instrumentation-fetch] refactor fetch() tests for clarity, type safety and realism #5268

chancancode commented Dec 14, 2024 •

edited

Loading

chancancode Dec 14, 2024

chancancode Dec 14, 2024 •

edited

Loading

chancancode Dec 14, 2024

chancancode Dec 14, 2024

chancancode Dec 14, 2024

chancancode Dec 14, 2024

chancancode Dec 14, 2024

chancancode Dec 14, 2024

chancancode Dec 14, 2024

codecov bot commented Dec 14, 2024 •

edited

Loading

chancancode commented Dec 18, 2024

pichlermarc left a comment

pichlermarc commented Dec 20, 2024

chancancode commented Dec 20, 2024

[instrumentation-fetch] refactor fetch() tests for clarity, type safety and realism #5268

[instrumentation-fetch] refactor fetch() tests for clarity, type safety and realism #5268

Conversation

chancancode commented Dec 14, 2024 • edited Loading

Which problem is this PR solving?

Short description of the changes

Type of change

How Has This Been Tested?

Checklist:

Choose a reason for hiding this comment

chancancode Dec 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Dec 14, 2024 • edited Loading

Codecov Report

chancancode commented Dec 18, 2024

pichlermarc left a comment

Choose a reason for hiding this comment

pichlermarc commented Dec 20, 2024

chancancode commented Dec 20, 2024

chancancode commented Dec 14, 2024 •

edited

Loading

chancancode Dec 14, 2024 •

edited

Loading

codecov bot commented Dec 14, 2024 •

edited

Loading