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!
Related
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?
So this is more of a theoretical question rather than a programming question.
In my basic understanding of the Angular 4 framework a component can have inputs, outputs and services which also interact with the store to store data.
Now all of this, in the case of a web-app is displayed on a template. I have recently been looking at testing of such an app.
I plan to use Jasmine as the framework and Karma as the test runner on Chrome (for now).
With that said, what should I be testing for?
According to my understanding the basic tests should include some mock object handed to the component and checking if that is rendered properly on the template, mocking a service and checking what is rendered when we receive the correct response.
So what do I do after this? After I have tested this?
How is this behavior driven development? What can I do more?
What is a "good angular test"?
Since you have mensioned jasmine with karma, My perspective of answering this question will be mostly on Unit Testing. Let us go one question after another
What is a "good angular test"?
1) Unit testing should be written by the developer not by anyone else (tester).
2) It must have both positive and negative scenarios handled.
3) All network calls should be mocked or stubbed.
4) It should pass irrespective of environment.
5) It should have be easily readable, reliable and should not test the integration.
How is this behavior driven development? What can I do more?
In a nut shell BDD:
1) Write unit test cases prior to your development
2) Let all of your unit test cases fail
3) Start with your development unit by unit. Pass the assertion.
4) BDD is a advancement of TDD. In BDD we should not test the implementation but behavior should be tested.
5) BDD increases the code quality as well since we create test case based on behavior.
So what do I do after this? After I have tested this?
Current trend as explained above, after writing the test cases start with the development. Write the assertion, even the non technical person can understand the behavior.
You should also check if your bread-crumbs are in position, bread-crumbs are used for internal routing between pages. Also use the right path of your routing component in your app-module.
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.
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?
When writing tests for React components, you have to render them into the DOM in order to make assertions about their correctness. For example, if you want to test that a certain class is added to a node given a certain state, you have to render into a DOM node, then inspect that DOM node via the normal DOM API.
The thing is, considering React maintains a virtual DOM into which it renders, why can't we just assert on the virtual DOM once the component is rendered? That seems to me like a very good reason to have something like the virtual DOM.
Have I missed something?
You haven't really missed anything. We're working on making this better. The virtual parts have always been very much an implementation detail of React, not exposed in any useful or reliable way for testing. We have some methods in our test helpers which wrap up the internal lookups which sometimes avoids looking at the actual DOM but we need more.