Skip to content

ref(nextjs): Improve integration test debugging #4144

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

Merged
merged 6 commits into from
Nov 15, 2021

Conversation

lobsterkatie
Copy link
Member

@lobsterkatie lobsterkatie commented Nov 11, 2021

This includes two changes I made to help myself while debugging the nextjs integration tests for a recent PR:

  1. Add the ability to set debug: true in Sentry.init() via a command line flag. In order to do this, I changed the --debug flag from a boolean to one which can appear multiple times and which accepts an optional string, either requests or logs, with the following behavior:

    • yarn test:integration -> no debug logging of any kind (matches current behavior)
    • yarn test:integration --debug -> sets debug: true in Sentry.init() (change in behavior)
    • yarn test:integration --debug logs -> sets debug: true in Sentry.init() (change in behavior)
    • yarn test:integration --debug requests -> logs intercepted requests (current behavior of --debug flag)

    I chose to make SDK debug logging the default (what you get if you just use --debug without an argument) because, of the two options, it is significantly more useful in my experience. (Logging intercepted requests gets unwieldy fast, as they are large objects and end up just creating a lot of noise to sift through in order to find the one piece of data you might want.) Since bare --debug has up until now logged intercepted requests, this is technically a breaking change, but since these tests have a userbase of under 5 people, all of them on our team, I figured we could probably roll with it. :-)

  2. Improve the VSCode debugger setup for the integration tests. This involved:

    • Adding a bash function to link sentry packages into the test app, so that we can test against any changes we make without having to reinstall all of the test app's dependencies again just to use the updated files.
    • Creating a task to be executed before each run of the debugger, which uses the above script to link monorepo packages (if not already linked) and then rebuilds the test app. (This happens by calling a new yarn script.)
    • Setting up the debugger's sourcemap config, so we can step through TS files rather than the generated JS files.
    • Adding more comments to the debug config to explain what each bit does and why.

@github-actions
Copy link
Contributor

size-limit report

Path Size
@sentry/browser - CDN Bundle (gzipped) 22.45 KB (-0.01% 🔽)
@sentry/browser - Webpack 23.35 KB (0%)
@sentry/react - Webpack 23.38 KB (0%)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped) 29.89 KB (-0.01% 🔽)

@lobsterkatie lobsterkatie merged commit a4108bf into master Nov 15, 2021
@lobsterkatie lobsterkatie deleted the kmclb-nextjs-improve-integration-test-debugging branch November 15, 2021 14:59
lobsterkatie added a commit that referenced this pull request Nov 15, 2021
This includes two changes I made to help myself while debugging the nextjs integration tests for a recent PR:

1) Add the ability to set `debug: true` in `Sentry.init()` via a command line flag. In order to do this, I changed the `--debug` flag from a boolean to one which can appear multiple times and which accepts an optional string, either `requests` or `logs`, with the following behavior:
    - `yarn test:integration` -> no debug logging of any kind (matches current behavior)
    - `yarn test:integration --debug` -> sets `debug: true` in `Sentry.init()` (change in behavior)
    - `yarn test:integration --debug logs` -> sets `debug: true` in `Sentry.init()` (change in behavior)
    - `yarn test:integration --debug requests` -> logs intercepted requests (current behavior of `--debug` flag)

    I chose to make SDK debug logging the default (what you get if you just use `--debug` without an argument) because of the two options, it is significantly more useful in my experience. (Logging intercepted requests gets unwieldy fast, as they are large objects and end up just creating a lot of noise to sift through in order to find the one piece of data you might want.) Since bare `--debug` has up until now logged intercepted requests, this is technically a breaking change, but since these tests have a userbase of under 5 people, all of them on our team, I figured we could probably roll with it. :-)

2) Improve the VSCode debugger setup for the integration tests. This involved:
    - Adding a bash function to link sentry packages into the test app, so that we can test against any changes we make without having to reinstall all of the test app's dependencies again just to use the updated files.
    - Creating a task to be executed before each run of the debugger, which uses the above script to link monorepo packages (if not already linked) and then rebuilds the test app. (This happens by calling a new `yarn` script.)
    - Setting up the debugger's sourcemap config, so we can step through TS files rather than the generated JS files.
    - Adding more comments to the debug config to explain what each bit does and why.
onurtemizkan pushed a commit that referenced this pull request Dec 19, 2021
This includes two changes I made to help myself while debugging the nextjs integration tests for a recent PR:

1) Add the ability to set `debug: true` in `Sentry.init()` via a command line flag. In order to do this, I changed the `--debug` flag from a boolean to one which can appear multiple times and which accepts an optional string, either `requests` or `logs`, with the following behavior:
    - `yarn test:integration` -> no debug logging of any kind (matches current behavior)
    - `yarn test:integration --debug` -> sets `debug: true` in `Sentry.init()` (change in behavior)
    - `yarn test:integration --debug logs` -> sets `debug: true` in `Sentry.init()` (change in behavior)
    - `yarn test:integration --debug requests` -> logs intercepted requests (current behavior of `--debug` flag)

    I chose to make SDK debug logging the default (what you get if you just use `--debug` without an argument) because of the two options, it is significantly more useful in my experience. (Logging intercepted requests gets unwieldy fast, as they are large objects and end up just creating a lot of noise to sift through in order to find the one piece of data you might want.) Since bare `--debug` has up until now logged intercepted requests, this is technically a breaking change, but since these tests have a userbase of under 5 people, all of them on our team, I figured we could probably roll with it. :-)

2) Improve the VSCode debugger setup for the integration tests. This involved:
    - Adding a bash function to link sentry packages into the test app, so that we can test against any changes we make without having to reinstall all of the test app's dependencies again just to use the updated files.
    - Creating a task to be executed before each run of the debugger, which uses the above script to link monorepo packages (if not already linked) and then rebuilds the test app. (This happens by calling a new `yarn` script.)
    - Setting up the debugger's sourcemap config, so we can step through TS files rather than the generated JS files.
    - Adding more comments to the debug config to explain what each bit does and why.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants