Skip to content

Remove prefer-expect-query-by rule from shareable configs #59

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

Closed
Belco90 opened this issue Jan 15, 2020 · 8 comments
Closed

Remove prefer-expect-query-by rule from shareable configs #59

Belco90 opened this issue Jan 15, 2020 · 8 comments
Assignees
Labels
enhancement New feature or request

Comments

@Belco90
Copy link
Member

Belco90 commented Jan 15, 2020

After checking prefer-expect-query-by rule with different people and getting different feedback about it, this rule is definitely too opinionated to be enabled by default in shareable configs. Also, the motivation of the rule is not really clear, so we need to improve the rule doc to clarify what's the use case and corresponding motivation for it.

@Belco90 Belco90 added the enhancement New feature or request label Jan 15, 2020
@Belco90 Belco90 self-assigned this Jan 15, 2020
@emmenko
Copy link
Contributor

emmenko commented Jan 15, 2020

Do you know what the confusion is about? Is the doc not clear enough? The main use case is when asserting that an element is not in the document, in which case it's recommended to use expect(queryBy as mentioned in the docs. The rule then ensures some sort of consistency of always using queryBy with expect.

Anyway, it's fine for me to not have it enabled by default, I'm just curious to know what people find confusing about it.

@Belco90
Copy link
Member Author

Belco90 commented Jan 15, 2020

I found this chat in spectrum about it: https://spectrum.chat/testing-library/general/prefer-expect-query-by-linting-rule~802a01db-1afd-4ca3-b753-1dfcfcc5d1ca

After that, I discussed with @thomlom about the rule and we agreed it looks too opinionated to be enabled by recommended preset. Then I shared with some coworkers and they found it as a weird rule by default too: the main though was "I completely understand how all recommended rules would help me writing testing library tests but not this one in particular".

About if doc is clear enough or not, examples could be improved and I would leave clear what use cases for this rules are (adding link to jest-dom section in testing library doc would help).

If you have anything else in mind we could improve here, let me know. I'll create a PR soon so we can improve it there too.

@emmenko
Copy link
Contributor

emmenko commented Jan 15, 2020

I see, thanks for the clarification. Yeah let's do it like this then.

@Belco90
Copy link
Member Author

Belco90 commented Jan 15, 2020

I guess that ideally we could have a rule enabled by default that forces you to use queryBy instead of getBy when asserting elements are not present, but I'm not sure how to implement that (checking expect().not.toBeInTheDocument and expect().toBeNull() or something similar? I'm afraid we would have to check tons of combination for different matchers and negations), so I think best think we can do for now is just not enabling it by default and specify which are the use cases.

@Belco90
Copy link
Member Author

Belco90 commented Jan 17, 2020

Closed by #60

@Belco90 Belco90 closed this as completed Jan 17, 2020
@Belco90
Copy link
Member Author

Belco90 commented Jan 17, 2020

@emmenko By the way: as discussed with Kent C in twitter, probably this rule should evolve to something that prevents using getBy queries when asserting element is not present or its disappearance instead of preventing just asserting always using getBy. That's complex as there are tons of different cases for that: asserting with .not.toBeInTheDocument(), asserting with .toBeNull(), asserting with .toBe(null), waiting for disappearance with waitForElementToBeRemoved (and maybe some more I can't think about now).

Would be a good addition for future versions.

@emmenko
Copy link
Contributor

emmenko commented Jan 17, 2020

Yeah definitely! Let's track this as an issue first.

@Belco90
Copy link
Member Author

Belco90 commented Jan 17, 2020

I'm creating an issue so we can discuss further details there.

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

No branches or pull requests

2 participants