2016-08-17 6 views
11

Я использую Enzyme для тестирования моих компонентов React. Я понимаю, что для проверки сырого несвязанного компонента мне пришлось бы просто экспортировать его и протестировать (я сделал это). Мне удалось написать тест для подключенного компонента, но я действительно не уверен, правильно ли это, и что именно я хочу проверить для подключенного компонента.Redux: Как проверить подключенный компонент?

Container.jsx

import {connect} from 'react-redux'; 
import Login from './Login.jsx'; 
import * as loginActions from './login.actions'; 

const mapStateToProps = state => ({ 
    auth: state.auth 
}); 
const mapDispatchToProps = dispatch => ({ 
    loginUser: credentials => dispatch(loginActions.loginUser(credentials)) 

}); 
export default connect(mapStateToProps, mapDispatchToProps)(Login); 

Container.test.js

import React from 'react'; 
import {Provider} from 'react-redux'; 
import {mount, shallow} from 'enzyme'; 
import {expect} from 'chai'; 
import LoginContainer from '../../src/login/login.container'; 
import Login from '../../src/login/Login'; 


describe('Container Login',() => { 
    it('should render the container component',() => { 
    const storeFake = state => ({ 
     default:() => { 
     }, 
     subscribe:() => { 
     }, 
     dispatch:() => { 
     }, 
     getState:() => ({ ...state }) 
    }); 
    const store = storeFake({ 
     auth: { 
     sport: 'BASKETBALL' 
     } 
    }); 

    const wrapper = mount(
     <Provider store={store}> 
     <LoginContainer /> 
     </Provider> 
    ); 

    expect(wrapper.find(LoginContainer).length).to.equal(1); 
    const container = wrapper.find(LoginContainer); 
    expect(container.find(Login).length).to.equal(1); 
    expect(container.find(Login).props().auth).to.eql({ sport: 'BASKETBALL' }); 
    }); 
}); 

ответ

12

Это интересный вопрос.

Обычно я импортирую как контейнер, так и компонент для проведения тестирования. Для испытаний контейнеров я использую, redux-mock-store. Тестирование компонентов для тестирования асинхронных функций. Например, в вашем случае процесс входа - это асинхронная функция с использованием sinon заглушек. Вот его фрагмент,

import React from 'react'; 
import {Provider} from 'react-redux'; 
import {mount, shallow} from 'enzyme'; 
import {expect} from 'chai'; 
import LoginContainer from '../../src/login/login.container'; 
import Login from '../../src/login/Login'; 
import configureMockStore from 'redux-mock-store'; 
import thunk from 'redux-thunk'; 
import { stub } from 'sinon'; 

const mockStore = configureMockStore([thunk]); 

describe('Container Login',() => { 
    let store; 
    beforeEach(() => { 
    store = mockStore({ 
     auth: { 
     sport: 'BASKETBALL', 
     }, 
    }); 
    }); 
    it('should render the container component',() => { 
    const wrapper = mount(
     <Provider store={store}> 
     <LoginContainer /> 
     </Provider> 
    ); 

    expect(wrapper.find(LoginContainer).length).to.equal(1); 
    const container = wrapper.find(LoginContainer); 
    expect(container.find(Login).length).to.equal(1); 
    expect(container.find(Login).props().auth).to.eql({ sport: 'BASKETBALL' }); 
    }); 

    it('should perform login',() => { 
    const loginStub = stub().withArgs({ 
     username: 'abcd', 
     password: '1234', 
    }); 
    const wrapper = mount(<Login 
     loginUser={loginStub} 
    />); 
    wrapper.find('button').simulate('click'); 
    expect(loginStub.callCount).to.equal(1); 
    }); 
}); 
+0

Было бы достаточно тестов для mapStateToProps и mapDispatch? – Umair

+0

Да, действительно. Вы должны проверить с помощью инструмента покрытия, вы найдете его полностью закрытым. – anoop

+1

. Фактическая вещь, которую я хочу знать, - это ЧТОБЫ проверить, когда мы собираемся протестировать контейнер/интеллектуальный компонент? – Umair

1

Как вы отметили, как я обычно делаю это, чтобы экспортировать не-связная компонента, как хорошо, и проверить это.

т.е.

export {Login}; 

Вот пример. Source of the component, и source of the tests.

Для обернутого компонента я не автор тестов для них, потому что мои сопоставления (mapStateToProps и mapDispatchToProps), как правило, очень просты. Если бы я хотел протестировать завернутый компонент, я бы просто тестировал эти карты. Таким образом, это то, что я бы выбрал для явного тестирования, а не для повторного тестирования всего компонента в завернутой форме.

Существует два способа проверки этих функций. Одним из способов было бы экспортировать функции внутри самого модуля.

i.e .;

export {mapStateToProps, mapDispatchToProps}

Я не большой поклонник этого, потому что я не хотел бы другие модули в приложении к ним доступ. В моих тестах я иногда использую babel-plugin-rewire для доступа к переменным «in-scope», так что я буду делать в этой ситуации.

Это может выглядеть примерно так:

import { 
    Login, __Rewire__ 
} 

const mapStateToProps = __Rewire__.__get__('mapStateToProps'); 

describe('mapStateToProps',() => { ... }); 
+0

Я сделал это. 'import Login from ../ login' является не подключенным компонентом. Причина, по которой я не использовал {Login}, состоит в том, что они лежат в отдельных файлах. – Umair

+0

Кроме того, что мне нужно для проверки компонента контейнера? – Umair

+0

О, я понимаю, что вы имеете в виду. До сих пор я не тестировал эти tbqh. Если бы я их протестировал, я бы использовал нечто вроде 'babel-plugin-rewire' и test' mapStateToProps' и 'mapDispatchToProps', а не сам упакованный компонент. – jmeas

Смежные вопросы