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

feat: Print link to the Testing-Library playground when getBy* queries fail #852

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

mathiassoeholm
Copy link

@mathiassoeholm mathiassoeholm commented Dec 19, 2020

What:

Adds a link to the Testing-Library playground, when getBy* queries fail, as requested in #837.

Why:

It adds awareness of the playground, which might help in making a better query.

How:

Changes the default getElementError function.

Checklist:

@codesandbox-ci
Copy link

codesandbox-ci bot commented Dec 19, 2020

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 07aa3a1:

Sandbox Source
react-testing-library-examples Configuration

@codecov
Copy link

codecov bot commented Dec 19, 2020

Codecov Report

Merging #852 (07aa3a1) into main (c273ed5) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##              main      #852   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           26        27    +1     
  Lines          966       977   +11     
  Branches       293       303   +10     
=========================================
+ Hits           966       977   +11     
Flag Coverage Δ
node-10.14.2 100.00% <100.00%> (ø)
node-12 100.00% <100.00%> (ø)
node-14 100.00% <100.00%> (ø)
node-15 100.00% <100.00%> (ø)
node-16 100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/config.ts 100.00% <100.00%> (ø)
src/playground-helper.ts 100.00% <100.00%> (ø)
src/screen.js 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c273ed5...07aa3a1. Read the comment docs.

@mathiassoeholm
Copy link
Author

It appears that Prettier might have formatted the inline snapshots differently, I'm not sure why 🤔

@mathiassoeholm
Copy link
Author

mathiassoeholm commented Dec 23, 2020

Before I will call this Ready to be merged, I have a few questions:

  1. Is it okay that I remove part of a test, that was causing the type check to fail? 43e7464 (Fixed by fix: add number support for matches #856)
  2. Should @types/lz-string be a dependency or a dev-dependency? I added it as dev dependency, because it doesn't provide any types to the public API.
  3. Why do I get a @typescript-eslint/no-unsafe-call lint warning, when I've added the types? Seems like this was a local issue in my editor, and it is gone now.

Screenshot 2020-12-23 at 12 24 01

4. Does anyone have a better suggestion for a text than "Open this DOM in the Testing-Library Playground"

@mathiassoeholm mathiassoeholm changed the title Pr/playground link in error message Add link to the Testing-Library playground, when getBy* queries fail Dec 23, 2020
@mathiassoeholm mathiassoeholm changed the title Add link to the Testing-Library playground, when getBy* queries fail Print link to the Testing-Library playground, when getBy* queries fail Dec 23, 2020
@mathiassoeholm mathiassoeholm marked this pull request as ready for review December 23, 2020 11:36
@mathiassoeholm mathiassoeholm force-pushed the pr/playground-link-in-error-message branch from f62b3a9 to 1f556b1 Compare December 23, 2020 11:54
@mathiassoeholm mathiassoeholm force-pushed the pr/playground-link-in-error-message branch from f2371c3 to b567f10 Compare January 4, 2021 20:00
Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for taking so long.

src/__tests__/get-by-errors.js Outdated Show resolved Hide resolved
src/__tests__/element-queries.js Outdated Show resolved Hide resolved
}

function getPlaygroundUrl(element: Element | null, logErrors = true) {
if (!element || !('innerHTML' in element)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (!element || !('innerHTML' in element)) {
if (element === null) {

Should be sufficient looking at the type definitions.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original if-statement in logTestingPlaygroundURL in screen.js look like this:

if (!element || !('innerHTML' in element))

So changing it will cause a behaviour change for that function. Are we okay with that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering we now have the type-safety I'm ok with it. Unless the types are inaccurate.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. 🤔
In screen.d.ts the type for the element parameter is Element | HTMLDocument. However HTMLDocument does not have an innerHTML property.

It's not really clear to me why logTestingPlaygroundURL accepts a HTMLDocument if it requires innerHTML at the same time.

Should I keep Element | null or is Element | HTMLDocument | null the correct type?
Perhaps the type definition in screen.d.ts needs to be updated.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another question: do we even want the | null? From the type definition it sounds like null is a valid value, when in fact it's an erroneous value to give as parameter.
If we do not have | null though, we will have to remove the first check or shut up ESLint with:

// eslint-disable-next-line @typescript-eslint/no-unnecessary-condition
if (!element) {

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update:

  • I have decided to remove the | null, so we're not "advertising" that null can be used as a valid value.
  • I don't think HTMLDocument is a valid type to use here, so to me it looks like that was an error in the old type definition.
  • I have removed a test that tried using {} as an argument and expecting The element you're providing isn't a valid DOM element. That error will no longer be logged if you're passing {}, because I removed the !('innerHTML' in element) check, and rely on static type checking instead.

Copy link
Member

@eps1lon eps1lon Jun 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That error will no longer be logged if you're passing {}, because I removed the !('innerHTML' in element) check, and rely on static type checking instead.

We generally don't relly on static type checking for users of our library. We may change that in the future but for now additional runtime errors should not be removed.

But these errors should happen in public methods. If getPlaygroundUrl is internal only then we can rely on static type checking and error should be thrown in the public methods using getPlaygroundUrl.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation, I think I get it now! I have added the runtime check again in logTestingPlaygroundURL.

src/playground-helper.ts Outdated Show resolved Hide resolved
@mathiassoeholm
Copy link
Author

Sorry for taking so long.

No worries! This is hardly an urgent issue, so thanks for taking the time to review :-)

@mathiassoeholm mathiassoeholm force-pushed the pr/playground-link-in-error-message branch from e938cd9 to bb23329 Compare January 24, 2021 15:59
@mathiassoeholm mathiassoeholm force-pushed the pr/playground-link-in-error-message branch from 4f71920 to 1c4f22b Compare January 27, 2021 17:41
@eps1lon eps1lon self-requested a review January 27, 2021 20:25
src/config.ts Show resolved Hide resolved
src/playground-helper.ts Outdated Show resolved Hide resolved
src/config.ts Outdated Show resolved Hide resolved
@mathiassoeholm mathiassoeholm force-pushed the pr/playground-link-in-error-message branch from cabd517 to 0b3d36e Compare May 12, 2021 20:02
mathiassoeholm and others added 2 commits May 12, 2021 22:03
Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com>
@eps1lon eps1lon changed the title Print link to the Testing-Library playground, when getBy* queries fail feat: Print link to the Testing-Library playground when getBy* queries fail Jun 2, 2021
@eps1lon eps1lon added the enhancement New feature or request label Jun 2, 2021
src/__tests__/screen.js Outdated Show resolved Hide resolved
types/screen.d.ts Outdated Show resolved Hide resolved
Comment on lines 13 to 15
function getPlaygroundUrl(element: Element) {
// eslint-disable-next-line @typescript-eslint/no-unnecessary-condition
if (!element) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
function getPlaygroundUrl(element: Element) {
// eslint-disable-next-line @typescript-eslint/no-unnecessary-condition
if (!element) {
function getPlaygroundUrl(element: Element | null) {
if (element === null) {

Let's match runtime and static types

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I touched upon this a little bit: #852 (comment)
Do you still think we should match the types, given that null is an erroneous type/value to pass in?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #852 (comment)

internal methods: static type checking
public methods: static type checking + extraneous runtime type checking for users not using static type checking

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the runtime checks has been moved to logTestingPlaygroundURL I was able to remove the if (element === null) from here :-)

@mathiassoeholm
Copy link
Author

@eps1lon I think I finally understood the difference between error handling in internal and public facing functions, so the PR should be ready again now :-)

Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eps1lon I think I finally understood the difference between error handling in internal and public facing functions, so the PR should be ready again now :-)

Mostly because I was side-lining this PR and didn't put much time into explaining what I think this PR should look like. Thank your for sticking with it 👍

I'll do some git hygene with the snapshot diffs, ensure compatibility with the alpha and then try it out in Material-UI to check if the playground link is not too noisy.

Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought: Are we sure this doesn't affect findBy* perf? getMissingError for Byrole has a special branch when called in findBy*. We need to make sure performance of findBy isn't affected by this change.

@golergka
Copy link

What's the status of this issue? I want something like this implemented and would love to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants