Así se organizan los componentes
class A extends React.Component { state = {mode: 'create'} abstract getRows() { } abstract getTitle(){ } } class B extends A { getTitle(){ if(this.state.mode === 'create'){ return 'New';} else {return 'Existing'}; } }Y en caso de prueba:
jest.mock('componentAFile'); component = shallow(<B />); component.setState({mode: 'create'}); expect(component.instance().getTitle()).toBe('New'); component.setState({mode: 'edit'}); expect(component.instance().getTitle()).toBe('Existing');Pero el modo de estado dice indefinido. ¿Cuál es la forma correcta de hacer esto? ¿Cómo probamos tales clases que heredan de las clases base?
Primero, mejor no uses ese enfoque de herencia. La composición es mucho mejor que ni siquiera puedo recordar ningún contra de la herencia.
En segundo lugar, al usar .setState , literalmente está accediendo a datos privados internos. O en otras palabras, "detalles de implementación". Hay tantos casos en los que se rompe repentinamente (propiedad renombrada en this.state , componente de clase refactorizado en función, descompone un componente en varios, etc.), que no hay razón para usarlo.
En tercer lugar, lo mismo ocurre con las pruebas de métodos internos. Nuevamente, son los detalles de implementación, tanto para el nombre, el orden de los argumentos, como para el resultado devuelto. Y además, supongamos que nunca usa esa función en qué componente se procesa en render() . Entonces la prueba pasará, pero el componente podría estar roto.
¿Qué puedes hacer en su lugar?
shallow(<B prop1={mockedValue} prop2={anotherValue} />); ).setProps )component.find('button').simulate('click') )expect(component.find('.title').text()).toBe('New')