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
Add getById and getByClass #683
Comments
You have other ways to query your elements better than class or id without using You can get your elements by text and also give it a try to queries like |
Thank you for the quick response, guys! @juandiegombr The problem with using @raoufswe The problem with using the approach with I was already aware of these breakthrough approaches to resolve this issue... but I really think it is not the ideal solution because of the issues that I mentioned above. In addition, using the
That's why I am in favor of creating a |
Nothing stops you to write you own query helper for Can you give an example where you have the same text twice? Most of the time I sorted this in different ways then cluttering up the HTML by adding |
Can you give an example where you have the same text twice? Facebook for example we have the same user name in different places of the same page. As I said, sometimes we can display the same text message in two different places of the DOM and it is not a good approach to restrict the functionality because of the testing suite. |
Precisely, if you really need them, you can add custom queries and using querySelector is very easy to do anyway so you can feel free to do that if you want. We're not going to add more direct support for querying by ID or class name than we already have so I'm going to close this issue. Just saw your message come in. For something like that you can scope your query using |
I was searching here also for the solution for this problem. I'm against to introduce hacks in the app code to write the tests. Because it will pollute the codebase with useless code that are only used on the tests. This will also increase the bundle pack size in a few bytes, what will affect the user page load in some degree. (I know that we can use another hack to remove the react-testing-library hacks during the the assets precompilation). Is good that we have ways to write our own finders to bypass this restriction, however since this approach is the standard for this library, this will leads many projects to go with the standard approach and by consequence adding all these problem discussed here. |
Adding Adding That's why I really believe that: Also, I used the Facebook as an example just to demonstrate that a well-known, well-designed and consolidated website can contain the same text in different parts of it, imagine the smaller sites then. |
I use testing-library in integration tests for whole pages. I usually have a few elements with the same text but there's always forms to get them without querying by class or by Id. Sometimes there is not a one line selector but It doesn't make it more difficult to read, instead it has other benefits as making more explicit and semantic your tests. As I said in my comment before, If we have accessibility in mind, that two elements with the text of |
Another issue is when we use third party libs to fill the HTML with elements dynamically and we have no control over what and how it will show... in addition, this third party library will eventually have new versions and change the way it display things on the page. On this case, the only possible way I can find to get the element the third party library renders is by injecting the ugly Since we don't have the
On the other hand, most libs that generates automatically html elements on the page already have a property called The new We will have a better control on the tests without polluting the code. Each case is different and the Removing the |
I took a time to investigate and discovered how to accomplish that import { configure } from '@testing-library/dom'
configure({ testIdAttribute: 'id' }) That's all I needed. |
you can't use |
@r3wt I upgraded the version of the Could you enable it again guys? @kentcdodds Thank you very much! |
Hi @Victorcorcos the behaviour is not changed, could you please add more details about your problem? Thanks |
With all the respect to the library authors/maintainers/contributors, as a first time user of this specific testing library I really feel like this project tries to enforce me to write code the way the testing library wants rather how I want. I do not object to projects promoting good coding standards, that is desirable. My markup was like this:
Following the prompts of this project, I used this line in my tests:
And due to a spec change, it the component became like this:
Now my test code is broken because I needed to wrap the text in a span element. Had i used a class selector, I wouldn't need to change my tests at all. According to this project I should go back to my markup and add a bunch of data-testids (which I am not inherently against) and fix all my test cases to use getByTestId. Not good times. How will I avoid this in the future? I will put a data-testid on everything, increase the amount of markup I write on my component and get rid of the getByRole/getByText selectors in my code (so what's the purpose of these selecotrs anyway then?) Is there a better way to structure my code to avoid this pain? Maybe there is. I can't think of it, sorry, maybe I am not as good at it as others. And I assume I can't rely on the help of volunteers on this forum to help me along the way as I build my app. So i have three options:
You see, I don't really wish to do any of those, all of these three options have a negative impact on my productivity. What I will probably end up doing is suck it up, deliver my current project and never touch this library again, which is sad because I think it has some serious benefits over some others. Edit: And all of that just because it doesn't fit with the philosophy of the project. Because nowhere did I see that this is not implemented due to code complexities or lack of resources. |
Just fyi to the maintainers, testing |
How do you test a component that does not have text without being able to use class name etc? I.e. something that renders like this?
|
@coler, for that case you use `getByRole('button', {name: 'close
dialog'});`, this will use the aria label to find it
…On Mon, 16 Nov 2020, 9:42 pm Coler, ***@***.***> wrote:
How do you test a component that does not have text without being able to
use class name etc? I.e. something that renders like this?
<button
aria-label="close dialog"
class="wv-close--large"
/>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#683 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AASLMLXZAVYLVP6BALOICGLSQGMD5ANCNFSM4NOR3EHQ>
.
|
@coler-j use |
@brendan-donegan @r3wt thanks guys, I found that a bit after commenting. Unfortunately stuck on v 9.5 where it doesn't seem to work. Working on getting my org updated. Thanks! |
This library shouldn`t force anything but provide as many helpers as possible, I'm also here stuck figuring out if I add the useless test-ids since there's no better option. |
The library gives access to normal DOM selectors so can do this const { container } = render(<Skeleton height={10} paragraph={4} />);
expect(container.getElementsByClassName('skeleton-paragraph-row').length).toBe(4); |
I want to express my opinion here sincerely. The text below may offend others, sorry.
For content such as text and aria-label that are easy to change, it is quite inappropriate to use them as selectors (and you guys even use regular expressions to increase the complexity of these selectors). One modification may cause a large number of selectors to fail, and then cause the test cases to fail. This is really not TDD. |
True, but the project prompts to use |
@BlackGlory I have the same problem as you (as posted earlier in this ticket), but turning on the heat against the developers of an open source library while asking them to support a feature... surely isn't beneficial. |
@gtsop why would it not be beneficial? These situations are what lead to forks in open source. Either the maintainers succumb to pressure from the community and provide this common sense feature, or the community will have had enough and fork the library. That?s just how it goes in open source. Everyone here while frustrated has remained respectful, even though the library maintainers design choices are effecting us in negative ways.On Tue, Jan 19, 2021 at 5:23 AM gtsop <notifications@github.com> wrote:
@BlackGlory I have the same problem as you (as posted earlier in this ticket), but turning on the heat against the developers of an open source library while asking them to support a feature... surely isn't beneficial.
?You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
|
I don't think we disagree here. The only thing you potentially missed is BlackGlory's characterization of getByText, getByName and getByTestId as jokes, with a clear disclaimer that his opinion might offend others. It didn't seem that much respectful and that's my only point here, the criticism is welcome and beneficial as you expressed. |
Hello, import { configure } from "@testing-library/dom";
export default function testAttribut(toDo, tag) {
configure({ testIdAttribute: tag });
return toDo();
}
const nav = testAttribut( () => getByText("totoDiv"), 'id') But after few more research I discovered the amazing function which is
from container, it's pretty useful (work like document.querySelector) ex: // const { contain } = render(<Component {...props}/>)
const iframe = container.querySelector("iframe");
const divId = container.querySelector("div#myId");
const divClass = container.querySelector("div#myClass");
const divIdInDivClass = container.querySelector("div#myClass > #otherId"); Some of you probably noticed the function but no mention as potential solution Hopefully some of you will find it useful, have a good day, regard! |
most useful! |
You must have missed my post above, |
I didn't cross the same problem as you so I can't really help you but I use to use fireEvent now that trigger some of my side effect. Before when I was using the enzyme library I did stuff like await act(async () => { stuff}) .... and now I do not need to use await any more. FireEvent doing it for us more simple ;) hopefully it's will help you |
I'm legitimately still trying to understand how the unique What gives? Why is there a FAQ telling me to deal with it, instead of simply explaining why it's better to introduce these changes to my codebase? It's legitimately concerning because if there's a good reason for it, which it certainly does, then it's lost in pretty much everyone if you slightly glance over this issue page. |
Instead of disallowing it, getById should be added with the library but with a warning indicate that its an "anti-pattern". |
You can do this: document.getElementById('id')
document.querySelector('.class-name') We're not adding an API to abstract that away. Just do that. |
Querying by id and classes is the Hello World of the frontend querying and the library doesn't allow that for now.
What about creating the
getById
andgetByClass
on the tests?Restricting the frontend id querying is not improving, it is quite the opposite, what is really does is decrease the capacity of the library.
Placing a lot of
data-testids
on the code pollutes it, because it places unnecessary tags on html codes in terms of code functionality. The code becomes polluted with tags only related for testing.I am in favor of TDDs, but adding things in the code (or worse: on html tags) only for testing is exaggerated. A good TDD will improve the code with more organization! A bad TDD will add things on code only related for testing purposes.
Some people can argue and defend the usage of
data-testids
on the code for whatever reason, but what I find uncomfortable is to disable for everybody the most basic querying on DOM elements.The text was updated successfully, but these errors were encountered: