docs: add marko testing library #159
Conversation
docs/marko-testing-library/api.md
Outdated
| template, // A Marko template to render | ||
| input, // Input for the above template | ||
| options // You won't often use this, expand below for docs on options | ||
| ): |
docs/marko-testing-library/api.md
Outdated
| > The [cleanup](#cleanup) function should be called between tests to remove the | ||
| > created DOM nodes and keep the tests isolated. | ||
|
|
||
| ## `render` Options |
There was a problem hiding this comment.
Docs looks great and solid! 👍
It's a bit weird, thou, that the "render options" section uses the same heading as the parent "render" heading. I'd suggest setting "render Options" as a third-level heading, and "container" as a fourth-level one.
Same thing with "render result" and its children.
😃
| ## `render` Options | |
| ### `render` Options |
There was a problem hiding this comment.
Excellent catches!
Updated the PR based on your comments.
Thanks for the review! 😄
There was a problem hiding this comment.
I realized I missed this part:
Same thing with "render result" and its children.
I think having those as a higher heading is still useful as it causes it to show up in the side nav (and these are probably the most important parts of the lib). This is also what the react-testing-library docs have setup (
There was a problem hiding this comment.
Totally right, I was thinking about that while typing, actually 🤔 Let's follow RTL example, then! If we ever feel the urge to change it we can make sure we update each framework docs :)
There was a problem hiding this comment.
I still like moving render Options as a sub heading, since in this package there is only one option and honestly it would be very rare that people use it. Could promote it to a higher heading (as is done in the react docs) if more options become available, but I don't see that happening.
In my last commit I updated the PR to do as I said above, but I left the render Result heading alone.
I think I'm happy with it now 😄
docs/marko-testing-library/api.md
Outdated
|
|
||
| ### `rerender` | ||
|
|
||
| It'd probably be better if you test the component that's doing the prop updating |
There was a problem hiding this comment.
I think this could be worded a bit more conservatively - rerender behavior is a valid thing to test for reusable components
There was a problem hiding this comment.
@alexkrolick I agree. This is a remnant of basing the docs off of the react ones.
Let me try to word smith this better.
There was a problem hiding this comment.
Updated this section of the docs, let me know what you think 😄
docs/marko-testing-library/setup.md
Outdated
| --- | ||
|
|
||
| `Marko Testing Library` is not dependent on any test runner, however it is | ||
| dependent on the test environment. These utilities work for testing both server |
There was a problem hiding this comment.
| dependent on the test environment. These utilities work for testing both server | |
| dependent on browser globals. These utilities work for testing both server |
There was a problem hiding this comment.
What are "these utilities" in this paragraph?
There was a problem hiding this comment.
Maybe test environment is not the most clear here. Basically I am trying to express that if your tooling does not pick up on the browser field in the package.json then your tests will be running in the SSR mode. For jest this just means enabling the browser option. Just having a global JSDOM for example (as is the default for jest) will not work by itself. It's a bit of a strange thing to explain to new comers though, do you have some thoughts on how to better describe this?
these utilities really just mean the api's exposed by the package. Maybe these apis would be better?
There was a problem hiding this comment.
Does that mean you can only test built files and not individual components? AFAIK most tests that require from the src folder aren't really aware of the packaging system.
There was a problem hiding this comment.
You can test individual components, the key is that by default the server side version of the component is resolved. For a client side version of a component to be resolved, the bundler, or test runner, needs to be aware of the browser field.
In Marko components are compiled to an optimized SSR streaming API or a VDOM api. The browser field is used to provide an appropriate runtime based on the environment.
|
Let's hold on merging this for now. Going to be addressing the comments above, and I also want to have a good solution for working with events emitted from Marko components. Will update this PR hopefully today 😄 |
|
Alright, I've improved the |
This PR adds documentation for the new
@marko/testing-libraryand closes testing-library/dom-testing-library#290.The above package is unreleased, but is ready to go hopefully along side this additional documentation!
Any feedback is much appreciated 😄