Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign uplog DOM on failing toBeInTheDocument() assertion #159
Comments
|
Makes total sense. Are you up to do this? |
|
Sure, why not! :) I just saw edited: wrote |
|
Hmmmm, good question. Not sure what's the preferred approach. Import it from DTL implies having to add DTL as a dependency (technically is |
|
If needed, we could extract one of those functions into a common package. Could even call it In theory this log should support the same env vars as the one in DTL for output length |
Sounds like an interesting idea. However, I fail to see other "utils" from current DTL implementation that would make their way to this shared package. What if we keep the discussion open (maybe other stuff could join Does it sound reasonable? |
Yep, let's just make sure we don't create a circular dep later |
|
Looks like jest-dom is already a dependency for DTL: https://github.com/testing-library/dom-testing-library/blob/master/package.json#L51. Will it be fine as long as we only import |
Hi!馃憢
Describe the feature you'd like:
.toBeInTheDocument()should (could) output the same error asgetByX()queries, so that it provides better context when debuggin what went wrong.There's a recommended rule in eslint-plugin-testing-library that suggests using
expect(queryByX('something').toBeInTheDocument())overexpect(getByX('something').toBeInTheDocument()).I get the point of the rule, as
getBywould already fail thus makingtoBeInTheDocument()redundant (even though I do this as I like to have explicit assertions in my tests). It is also useful as you don't have to "choose" between get/query when testing whether if an element is in the DOM or not.However, the error message users get from
getByqueries is far superior totoBeInTheDocument(), as it outputs the actual structure of DOM nodes, so you get immediate feedback of what's being rendered.Thus, my suggestion is that a failing
toBeInTheDocument()assertion should print the DOM nodes, giving a real equality betweengetByvs.queryBy+toBeInTheDocument().Thoughts?馃檶
Thank you!
An image is worth a thousand words:
This is the output of a failing
queryBy+toBeInTheDocument()assertion:This is the output of a failing
getBy+toBeInTheDocument()(optionally) assertion: