unit testing - mock - Pruebas unitarias de aplicaciones React/Redux.

react redux testing

Question

Actualmente estoy investigando enfoques de prueba para aplicaciones basadas en Redux / React. Pasé por un tutorial de redux sobre pruebas, pero aún tengo preguntas:

1. ¿Tiene sentido probar a los creadores de acción simple, que simplemente devuelven un objeto con el type y el campo de payload ? Para mí, huele a pruebas de getter/setter en aplicaciones OO.

2. En el caso de probar una acción asíncrona, ¿debe verificar que las acciones de éxito correspondientes y se envíen? Una vez más, con las solicitudes HTTP simuladas, parece que solo se están probando los contenedores de mock, no el comportamiento de la aplicación.

3. ¿Debería centrarse la prueba en los reductores, ya que son responsables de las transiciones de estado, medios para un comportamiento de los componentes conectados?

4. Tal vez, en lugar de probar el coraje de la aplicación, ¿debería probarse más en un nivel de componentes? ¿Qué aspectos del componente deben ser probados cuando? ¿Son frágiles esas pruebas?

Me gustaría escuchar alguna experiencia de personas que usan Redux / React en la producción y practican activamente las pruebas.

Answer 1

Daré una respuesta a cada pregunta, a su vez, solo con diferentes niveles de detalle correspondientes a mi experiencia.

dr : enfóquese en el comportamiento específico de la aplicación y las pruebas de características, deje que las bibliotecas se preocupen por los detalles de implementación de redux y pruebe las funciones de reductor pequeño antes de usarlas en componentes.

1. Si usas una abstracción como redux-actions como hice inicialmente usando redux, entonces no realmente. Si está devolviendo manualmente objetos con las mismas propiedades una y otra vez, solo configure un caso de prueba simple que recorra los creadores de acciones expuestos, los llame con valores y verifique los tipos de objetos devueltos. Exagerar para unos pocos, pero se convierte en una prueba de salud mental barata cuando tienes muchos creadores de acción. Ex:

   for (var i = 0; i < actions.length; i++) {
   let action = actions[i](testData);
   expect(action).to.have.property(''type'');
   expect(action).to.have.property(''payload'');
   }

2. Una pregunta confusa, pero en cualquier caso la experiencia me ha enseñado a probar en exceso las cosas relacionadas con la red. Cubra los casos de borde debido a los tiempos de espera y agregue algunas expectativas sobre la forma de la respuesta a los reductores y el orden en que fueron llamados.

3. Sí, debería centrarse en los reductores . Esta es la pregunta más importante, ya que se relaciona con una de las razones por las cuales el redux es exitoso. Todo es funciones simples combinadas en funciones poderosas y fáciles de razonar (reductores).

   Así que si tuviéramos:

   const reducer = combineReducers({
   a: reduceA,
   b: reduceB
   })

   Luego pruebe el comportamiento de cada reductor ( reduceA y reduceB ) en casos de prueba separados. Aún desea probar los resultados devueltos y sus formas, pero siempre intente dividir los reductores tanto en la implementación como en la prueba.

4. Como antes, debe tener pequeñas funciones en uso y sus implementaciones se están probando antes de ser utilizadas en un marco de componente específico (aquí se supone que reaccion.js). Si sigues los consejos dados en la docs

   Es recomendable que solo los componentes de nivel superior de su aplicación (como los controladores de rutas) conozcan Redux. Los componentes debajo de ellos deben ser representativos y recibir todos los datos a través de accesorios.

   Luego, todo lo que tiene que probar es que los componentes de nivel superior pasan el dispatch de redux y luego si los componentes simples llaman a los manejadores como onClick , o extraen el estado correcto de su tienda, pero estos solo deben ser simples espías o afirmaciones en el La forma y el valor de los accesorios, no están realmente relacionados con el redux.

Answer 2

Puede intentar utilizar redux-actions-assertions de acciones de redux-actions-assertions para probar acciones y creadores de acciones. Permite escribir afirmaciones legibles de una línea y evitar la fase de preparación de la tienda.