Background: Many of my auto tests are testing UI components. Every time a test fails it's difficult to debug. It would be very helpful, if the given test input could be rendered, so I can have a look at what is going on.
Storybook provides exactly that feature: Define some input and render the component in that state.
In general, UI auto test cases are often also cases I might also want to check visually at times.
Problem
Test cases are structured hierarchically with describe and test. Stories need to have a flat structure, because they need to export.
As soon as I add an test('', ()=>{}); to my .stories.tsx file, storyboard stops showing the component (silently, not showing any error).
Question
How can I easily add my test case content (what's inside render) to storybook?
Related
Simply test case: Want to see if a given element is focused.
To check if an element is focused on a react web app with RTL and jest, you have two easy options available to you:
You can check if the element is the same as document.activeElement (may have to discard some wrappers)
You can extend your jest matchers with https://github.com/testing-library/jest-dom#tohavefocus and use expect(<element>).toHaveFocus()
I'm not sure what the equivalent check would be with react native (the RN equivalent to the jest-dom extension is https://github.com/testing-library/jest-native and is conspicuously missing the toHaveFocus matcher).
Sunk several hours in to this today. From what I can see, React Native Testing Library doesn't have this matcher and neither does the Jest Native matcher extender.
It looks like Detox supports it though.
There are lots of suggestions to use refs (which might let us call ref.current.isFocused()), or capture onFocus\onBlur events. But these aren't viable from the test environment perspective.
There were 2 things I observed with the refs.
The refs all get mocked out in jest (I don't know enough about jest to know why).
When the element is not focused, the ref is completely gone
Regarding, tracking onFocus\onBlur, it's unnecessary overhead and only further complicates the production code for the sake of testing. Then the component has to accept these as props and a mock has to be created for each one... no thanks!
I decided to open a feature request in the Jest Native project. Cross your fingers.
React.js users have it so easy!
I've been learning how to write automated tests for a React app, and it's brought up questions on how best to test a series of interactions with the app.
Let's say that I have a React app that allows the user to assign students to seats in a classroom: Here's an image of what such an app would look like.
I'd like to test creating a new student, adding that student to a seat in the classroom, and then moving that student back to the area of unseated students in the middle column (I'll call it the roster).
What would be the best way to write out the test(s) for this? Would it make sense to have a single large test case, which would include assertions for each of the interactions I'm testing (creating a new student, moving it between the classroom and roster)?
Or should I create multiple cases, where one depends on the other? In other words...
Test 1) Check that a new student is created successfully when submitting the form
Test 2) Using the student created in test 1, move the student to a seat in the classroom
Test 3) With the student now in a seat (due to test 2), move it back to the roster area
Another question I have is whether React Test Library would be sufficient for this purpose. Or would this be considered an end-to-end test that should be written using Cypress?
Your feedback is much appreciated!
The process you described can surely be tested with react-testing-library as an integrated test. From the docs/faq, it encourages testing a component high enough up the component tree, without mocking child components, in order to simulate and test what an actual user interaction would be like.
Also check out this Kent C. Dodds blog post .
You want your tests to be as granular as possible, as you have already split them in 3 different cases. This will make it easier for everyone to read your code.
As for the testing library, I would go with Cypress which advertises itself as a JavaScript End to End Testing Framework.
You are testing end-to-end functionality here by manipulating what seem to be multiple components. React testing library, on the other hand, seems to focus on testing individual components on a more low-level approach - there's a chance it will falter on the long run, but it probably gets the job done aswell.
I'm trying to test the output of Mithril.js components to programmatically verify that they look how they are intended to. What would be the best way to go about doing this? I'm working with the Jasmine testing framework.
I've been looking for a library that could take a Mithril component and easily verify that it has some element with so many of some other element as the children, and they have some set of properties. Essentially, I'm looking for something like Enzyme that works with Mithril. Of course, I want something as decoupled as possible from the implementation of the code.
I've looked into the library mithril-query, which verifies the existence of elements through CSS selectors, but I've had issues with it not working with compound selectors, and the syntax isn't visually intuitive. I would also just like to know if there are any other options available.
You could try mithril-node-render combined with your favorite HTML assertion tool.
What is the best way to test React's Components in Unit Tests?
The first problem is decorators (or HOCs). We don't want to test them, but without them it is really hard to mount deeply to test how it works as a components; but in order to make them work we have to mock all chain of Providers (which is ~3 components in our case, plus contexts, etc), and again, it is too fragile from my point of view.
Next question is about the logic inside components. I know, there are tons of articles with cool advice like "don't use logic inside your components", but we often need to maintain local state (like banners, etc). Should it be tested just with shallowMount, or it doesn't cost it too? Also lifecycle methods, if we start to check it, doesn't it make our tests too brittle and too much know about implementation?
And the last question is about the markup. Should we check anything inside the React Component? I read all sorts of tutorials, and I think that finding by tag is the worst example ever (I don't even want to go into details here). Jest snapshot feature for me doesn't seem a good choice too (I see absolutely the same problems here too). What I see could be helpful – just checking that different components are rendered when difference props are passed (like Loader and Offer, for instance, respectively), but sometimes they are children of some container itself, and shallowRendering doesn't work, which takes us back to the initial point.
To conclude, I see the point only in two things:
Testing logic for internal state (invoking methods and looking into new state)
Looking at rendering of components which render depending on props.
Second point can be really hard (because of deep nested children), so for now I am leaning towards rendering just a component (check that it didn't fail – in a shallow way), and checking logic by invoking methods and checking state after.
What are your strategies?
I am looking at the React Test Utilities docs, in particular at the renderIntoDocument function:
Render a component into a detached DOM node in the document.
I am wondering whether I should be doing anything with the component that I've rendered once I'm done testing?
This works:
const component = ReactTestUtils.renderIntoDocument(createElement(MyThing));
// do tests
unmountComponentAtNode(findDOMNode(component).parentElement);
but I'm wondering if this step is necessary, since it isn't mentioned in the docs. Does my current approach actually achieve anything useful, or can I just use renderIntoDocument without worrying about tidying up?