He creado un componente de reacción simple y escribo casos de prueba de componentes que funcionan correctamente. Tengo un informe de cobertura para los casos de prueba.
Ahora, he agregado reaccionar redux en mi otro componente. este componente contiene los métodos componentDidMount() y export default connect(null, updateProps)(ComponentName). Necesito escribir casos de prueba de unidad para estos métodos.
Consulte el ejemplo de código a continuación,
class MyComponent extends Component { componentDidMount = () => { //some code here ) handleSignIn = (e) => { //some code here } render() { return ( <div> <form onSubmit={this.handleSignIn}> <Input type="text" name="inputText" placeholder="Text" autoFocus required /> </form> </div> ); } const updateProps = (dispatch) => { return { //some code here }; }; export default connect(null, updateProps)(MyComponent);En tu código tienes dos cosas:
class MyComponenty
const thisIsBasicallyAnotherComponent = connect(null, updateProps)(MyComponent);Entonces, si desea probar su componente, básicamente tiene dos opciones. Puede probar su componente envuelto y conectado a la tienda redux o puede escribir una prueba de unidad simple para su componente de clase tal como está.
Lo que recomendaría hacer es exportar su componente de clase
- class MyComponent extends Component { // replace this + export class MyComponent extends Component { // with thisY luego puede probar su componente React con Jest como cualquier otro componente.
test('Link changes the class when hovered', () => { const component = renderer.create( <MyComponent {...mockProps} /> // !! keep in mind that you have to manually pass what you have in `updateProps` because the component is not connected to Redux store anymore ); // ... write your test and expectations here });De lo contrario, puede probar su componente conectado (lo que se exporta de forma predeterminada), pero luego tendría que envolver el componente en el proveedor de Redux para poder probarlo.
Puede encontrar más información sobre las pruebas aquí:
Puede usar el Provider de react-redux o redux-mock-store para evitar la necesidad de usar un reductor real:
import { Provider } from 'react-redux'; import configureStore from 'redux-mock-store'; import MyComponent from './MyComponent.jsx'; const mockStore = configureStore([thunk]); it('does something on mount', () => { // let's mock some Redux state const store = mockStore({ slice1: { id: 2, name: '11' } }); mount(<Provider store={store}><MyComponent /></Provider>); expect(store.getActions()).toContainEqual({ type: 'some-type', payload: .... }); }); Pero esto es tan fácil solo para acciones simples. ¿Qué sucede si usa redux-thunk y hay algo de carga? Hay 2 formas:
redux-thunk a mockStore y mock network, por ejemplo, usando mock-fetch o nock . Más fácil de configurar, pero también podría ser excesivo si ya prueba su Redux directamente, repetir las pruebas para "falló la carga", "la carga tarda mucho", etc. también en su componente significaría doble trabajo.../yourPath/actions.js para que cada acción allí sea un objeto simple, no un thunk. Normalmente voy de esta manera. Pero, ¿qué hay de "exportar el componente sin envolver para que podamos probar el componente de forma aislada, sin Redux"? Verá, estaba funcionando cuando connect era la única API posible. Pero ahora, con ganchos como useSelector , useDispatch , useStore en mente, es mucho más confiable hacer primero pruebas para "mi componente EN Redux". De lo contrario, con el enfoque de "exportaciones dobles", podemos descubrir que convertir el componente de clase a función significa mucho más trabajo en las pruebas de parches, no en el componente en sí.