-
Notifications
You must be signed in to change notification settings - Fork 33
The returned container
is one level too high compared to other frameworks
#313
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
Comments
First, kudos for the detailed explanations. Even with that, I had to re-read it many times before my head stopped swimming with the overloaded meanings of target and container. :-)
That all make sense to me. It aligns the terminologies as best as possible.
I think we're better to stick with
Yeeeah, it's one of those that sounds good because it's slightly less typing, but what was "first argument is what svelte needs -- you know Svelte and will feel at home there -- second argument is what the testing lib need -- don't worry much, you'll hardly ever use it", will become "there is one argument that is what you're used to, but not quite. Also if Svelte or the testing library change something it'll be a bucket of fun". I approve of the sentiment, but think this path leads to dragons. |
🎉 This issue has been resolved in version 4.2.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# Motivation Testing library [v5.0.0](https://github.com/testing-library/svelte-testing-library/releases/tag/v5.0.0) introduces a breaking change that changes the returned `container` position (see issue [#313](testing-library/svelte-testing-library#313)). # Changes - use `baseElement` instead of `container` when our test actually expect the body to perform search - adapt `rerender` which are now promises and do not expect the `props` parameter --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Overview
The
render
function provides two options for changing how a component gets rendered into the DOM:componentOptions.target
andrenderOptions.container
. It returns aresult.container
element.componentOptions.target
is the target element the component is rendered into<div>
that we createrenderOptions.container
is the element thattarget
is inserted intodocument.body
result.container
returnsrenderOptions.container
These option names and their behaviors are different in confusing ways from other
testing-library
frameworks that makesvelte-testing-library
a little more difficult to use than its siblings. The primary issue is that by default we returndocument.body
rather than the createddiv
forresult.container
.Expectations
container
baseElement
target
container
The main issue I have is
result.container
is one level higher than I expect. The most common way I notice this is that I expectcontainer.firstChild
to be my component's first node. Instead, it iscontainer.firstElement.firstElement
.This expectation comes from the react-testing-library docs:
Proposed changes
Since there are definitely breaking changes on the horizon due to Svelte moving on from v3, I think there's an opportunity here to align the
render
API with all the other libraries.I think a small but effective change set would be:
container
option tobaseElement
baseElement
(root) asresult.baseElement
target
(the wrapping<div>
) asresult.container
target
is provided, use it as thebaseElement
and do not create/insert any other elementsI think there are a few other changes we could consider:
target
option tocontainer
componentOptions
andrenderOptions
into a singleoptions
objectvue-testing-library
Relates to #312
The text was updated successfully, but these errors were encountered: