Redux: 공급자에 래핑되거나 Enzyme과 연결하여 컨테이너를 참조할 수 없습니다.

connect() 도 Provider 도 이 라이브러리의 일부가 아닙니다. 대신 적절한 저장소( https://github.com/reactjs/react-redux)에 문제를 제출하면 이러한 문제를 논의하고 추적하는 것이 더 쉽습니다.

나는 그것이 실제로 의미가 있다고 생각합니다. 얕은 렌더링이므로 Provider 구성 요소만 렌더링됩니다. ContainerComponent는 개체 출력 형식이나 얕은 렌더링이 생성하는 모든 형식으로 남습니다.

두 가지 생각:

먼저 connect() 에 의해 생성된 래퍼 구성 요소는 $ context.store 를 찾기 전에 실제로 props.store 를 찾습니다. 따라서 실제로 연결된 구성 요소를 테스트해야 한다고 생각한다면 , 제공자나 컨텍스트 등에 대해 걱정할 필요 없이 <ConnectedComponent store={myTestStore} /> 를 렌더링할 수 있어야 합니다.

두 번째 질문은 완전히 연결된 구성 요소를 실제로 테스트하는 것에 대해 정말로 걱정할 필요가 있는지 여부입니다. 내가 본 주장은 "일반" 구성 요소를 특정 props로 테스트할 수 있고 mapStateToProps 구현을 테스트할 수 있다면 react-redux가 이를 올바르게 결합할 것이라고 안전하게 가정할 수 있다는 것입니다. 연결된 버전 자체를 실제로 테스트할 필요가 없습니다.

@gaearon 맞습니다 죄송합니다. 반응 또는 효소 저장소에서 이것을 올릴지 여부를 몰랐습니다.

@markerikson 스마트 구성 요소를 테스트하는 이유는 mapToDispatchProps 에 대한 것입니다. ConnectedComponent 에 상점을 전달하기만 하면 상태 매핑이나 디스패치 콜백 기능을 테스트하지 않을 것입니다.

이에 대해 더 생각해보고 필요하면 관련 레포에서 문제를 제기하겠습니다. 도와 주셔서 감사합니다.

@mordra : "올바른 디스패처가 호출되었습니다"라고 말하면 실제로 "올바른 작업 작성자"를 의미합니까?

다음과 같이 할 수 있습니다(구문은 아마도 꺼져 있지만 아이디어는 얻어야 함).

let actionSpy = sinon.spy();

let wrapper = shallow(<PlainComponent someActionProp={actionSpy} />);
wrapper.find(".triggerActionButton").simulate("click");
expect(actionSpy.calledOnce).to.be.true;
expect(actionSpy.calledWith({type : ACTION_I_WAS_EXPECTING)).to.be.true;

다시 말해, 일반 구성 요소를 렌더링하고 mapDispatch 에서 반환된 작업이 될 소품에 대한 스파이를 전달하고 구성 요소가 해당 작업을 호출하도록 하는 데 필요한 모든 동작을 트리거합니다.

또한 이전 의견에 따르면 mapStateToProps 및 mapDispatchToProps 를 개별적으로 테스트할 수 있어야 하며 연결된 버전을 테스트하려고 시도하지 않고도 React-Redux가 적절하게 호출할 것이라는 확신이 있어야 합니다. 그 자체를 확인하는 것입니다.

@markerikson 내 PlainComponent 는 액션이나 액션 제작자에 대해 알지 못하기 때문에 당신이 제안하는 것을 할 수 없습니다. 이것이 올바른 방법인지는 모르겠지만 다음을 보면 다음과 같습니다.
https://github.com/mordra/cotwmtor/blob/master/client/charCreation/charCreation.jsx
내 mapDispatchToProps 에 모든 논리가 포함되어 있음을 알 수 있습니다.

const mapDispatchToProps = (dispatch) => {
  return {
    onCompleted      : (player) => {
      Meteor.call('newGame', player, function (data) {
        console.log('new game return: ' + data);
      });
      dispatch(routeActions.push('/game'));
      dispatch({type: "INIT_GAME", map: generateAreas(), buildings: generateBuildings(dispatch)});
    },
    onCancelled      : () => dispatch(routeActions.push('/')),
    onChangeName     : input => dispatch(actions.changeName(input)),
    onChangeGender   : gender => dispatch(actions.setGender(gender)),
    onSetDifficulty  : lvl => dispatch(actions.setDifficulty(lvl)),
    onChangeAttribute: (attr, val) => dispatch(actions.setAttribute(attr, val))
  }
};

그래서 PlainComponent에 전달된 props를 염탐하면 올바른 조치가 호출되었는지 테스트할 수 없지만, 오히려 조치 작성자에게 전달된 매개변수가 올바른지 여부를 테스트할 수 없습니다.
그런 다음 connect 구성 요소를 별도로 테스트해야 합니다.

아. 그것은 내가 더 많은 것을 이해하는 데 도움이됩니다.

따라서 실제로 테스트를 작성하는 실제 경험이 거의 없다는 경고와 함께 몇 가지 생각이 있습니다.

• 실제로 액션 생성자가 있는 것은 dispatch 에 대한 액세스를 원하기 때문에 별도로 정의되지 않았을 뿐입니다. 그것은 그 자체로 쉽게 테스트할 수 없습니다. 아마도 그들의 행동을 테스트할 수 있기를 원할 것이고, 그렇게 하기 위해 mapDispatch 외부의 자체 함수로 정의하기를 원할 것입니다.
• 이것들은 모두 redux-thunk와 함께 사용하기에 아주 좋은 후보처럼 보입니다. 그러면 확실히 이러한 함수를 자체적으로 정의하고 dispatch 에 액세스할 수 있습니다.
• 귀하의 PlainComponent는 _does_ "액션"에 대해 알고 있습니다. 또는 이 경우 최소한 콜백을 전달하고 있다는 점에서, 그리고 컴포넌트의 어딘가에서 this.props.onSetDifficulty("HARD") 또는 이와 유사한 것을 실행하고 있습니다. 내가 행동을 위해 스파이를 보낼 것을 제안했을 때, 이것은 내가 교체를 제안한 종류의 것입니다. 따라서 onSetDifficulty 에 대한 스파이를 전달한 경우 구성 요소가 이를 호출하고 난이도 수준에 대해 허용되는 값을 전달했는지 확인할 수 있습니다.

궁극적으로 mapDispatch 에 정의된 함수를 사용하여 개별적으로 정의하여 훨씬 더 테스트 가능하게 만들 수 있어야 한다고 생각합니다. 그러면 구성 요소를 올바르게 테스트하기 위해 mapDispatch 를 연결해야 하는 것에 대해 걱정할 필요가 없으며 구성 요소가 올바른 인수 또는 다른 것으로 지정된 prop 콜백을 호출했는지 여부에 집중할 수 있습니다.

또한 구성 요소의 관점에서 보면 궁극적으로 {action: CHANGE_NAME, name : "Fred"} 가 발송되었는지 여부에 대해 실제로 걱정하지 않습니다. 그것이 아는 것은 this.props.onChangeName("Fred") 라고 했고 _that_ 은 당신이 테스트하려고 시도해야 하는 것입니다 - 그것이 올바른 방법으로 prop 콜백을 호출했다는 것입니다.

@mordra 귀하의 경우 mapDispatchToProps 를 내보내고 격리하여 테스트합니다. 속성 이름이 모두 올바른지 확인하고 작업 작성자를 테스트하기 위해 파견용 스파이를 전달할 수 있습니다.

즉, 나는 mapActionCreatorsToProps를 선호하여 mapDispatchToProps 를 피하는 경향이 있습니다. mapActionCreatorsToProps 는 독립적으로 쉽게 테스트할 수 있는 이미 형성된 액션 제작자를 매핑합니다. 이 경우 모든 소품이 가져오기 오타를 방지하도록 정의되어 있는지 테스트합니다.

마지막으로 일반(얕지 않은) 렌더링을 사용할 수 있습니다. 이를 위해서는 jsdom이나 실제 브라우저가 필요하지만 모든 수준에서 렌더링할 수 있습니다.

반응 또는 효소 저장소에서 이것을 올릴지 여부를 몰랐습니다.

죄송합니다. 나는 React 또는 Enzyme repos를 의미하지 않았습니다. 나는 당신이 사용하고 있는 라이브러리인 React Redux 를 의미했습니다.

도움을 주셔서 감사합니다. 내가 가서 소화해야 할 많은 정보입니다. @markerikson @fshowalter 주변을 좀 더 둘러보고 mapState/Dispatch를 내보내고 별도로 테스트하자는 제안을 받아들일 것입니다. 예상되는 동작을 유발하는 콜백을 테스트하는 것이 합리적입니다.

@gaearon Stateless 구성 요소는 얕게 문제를 훑어보지 않고 렌더링되지 않습니다. 중첩된 stateless 구성 요소가 있는 stateful 구성 요소를 렌더링하는 데 문제가 있는 것 같습니다. 그래서 지금은 그 경로를 피하기 위해 메모를 했습니다.

어떤 문제를 말씀하시는지 모르겠습니다. 기능적 구성 요소와 함께 얕은 렌더링을 사용할 수 있습니다. 얕은 렌더링은 한 수준 깊이에서만 작동합니다(구성 요소가 정의된 방식에 관계없이). 이것이 주요 기능입니다. 반복되지 않으므로 구성 요소 테스트가 독립적으로 유지됩니다. 재현할 수 있는 얕은 렌더링과 관련된 특정 문제가 있는 경우 React 저장소에 버그를 제출하세요. 감사 해요!

@gaearon : 명확히 하기 위해 이렇게 하면:

let wrapper = shallow(<A><B /></A>);

B가 렌더링됩니까, 아니면 렌더링되지 않습니까? 그것이 원래 질문이었던 것 같아요 - 연결을 테스트하기 위해 연결된 구성 요소 주위에 <Provider> 를 렌더링하려고 했습니다.

Redux와 직접적인 관련은 없지만. 컨테이너에서 shallow() 를 다시 호출하여 이 문제를 해결했습니다. 스토어 상태가 전달된 내부 구성 요소를 렌더링합니다.

예시:

import React from 'react';
import {expect} from 'chai';
import {shallow} from 'enzyme';
import configureMockStore from 'redux-mock-store';
import thunk from 'redux-thunk';
import events from 'events';

const mockStore = configureMockStore([ thunk ]);
const storeStateMock = {
  myReducer:{
    someState: 'ABC'
  }
};

let store;
let component;
describe('tests for MyContainerComponent', () => {
  beforeEach(() => {
    store = mockStore(storeStateMock);
    component = shallow(<MyContainerComponent store={store} />).shallow();
  });

  it('renders container', () => {
    expect(component.find('div.somediv')).to.have.length.of(1);
  });
  ...
});

도움이 되었기를 바랍니다

커스텀 모듈을 통해 더 접근하기 쉬운 방법을 만들어야 할까요?

편집: 연결을 component = shallowWithConnect() 와 같은 Enzyme에 대한 하나의 방법으로 선언할 수 있습니다.

@ev1stensberg 이것은 좋은 생각입니다. 이것이 접근 방식인지 및/또는 이에 대한 작업이 시작되었는지 결정했습니까? 그렇지 않다면 기여하고 싶습니다.

미래에 이 문제를 우연히 발견한 사람을 위해 저에게 적합한 접근 방식이 있습니다. 일반 구성 요소를 자체적으로 테스트하기만 하면 됩니다. 구성 요소 정의를 명명된 내보내기로 내보내고 연결된 구성 요소(앱에서 사용하기 위해)를 기본 내보내기로 내보냅니다. 원래 질문의 코드로 돌아갑니다.

// test
let component = shallow(<Provider store={store}><ContainerComponent /></Provider>);
component.find('#abc'); // returns null

let component = shallow(<Provider store={store}><div id="abc"></div></Provider>);
component.find('#abc'); // returns the div node

// ContainerComponent
export const Component = ({...}) => (<div id="abc"></div>); // I EXPORT THIS, TOO, JUST FOR TESTING
export default connect(..., ...)(Component);

그럼 그냥

const component = shallow(<Component {...props} />)
// test component

그리고 위에서 다른 사람들이 지적했듯이 연결에 전달하는 기능에 대한 적용 범위가 있다면 구성 요소 전체에 대한 전체 적용 범위가 있어야 합니다.

자, 여기서 가장 먼저 주목해야 할 것은 :

1. 상점에서 상태를 전달합니다.
2. 기반으로 디스패치 작업을 통해 상태를 수정합니다. 이벤트.

내가 괜찮다면 다음 두 가지만 테스트하면 됩니다.

1. 구성 요소가 상태에서 생성된 올바른 소품을 수신하고 있습니까(선택자를 통해 가능)?
2. 구성 요소가 올바른 작업을 전달하고 있습니까?

이것이 내 접근 방식입니다.

import React from 'react';
import { shallow } from 'enzyme';
import { fromJS } from 'immutable';
import { createStore } from 'redux';
// this is the <Map /> container
import Map from '../index';
// this is an action handled by a reducer
import { mSetRegion } from '../reducer';
// this is an action handled by a saga
import { sNewChan } from '../sagas';
// this is the component wrapped by the <Map /> container
import MapComponent from '../../../components/Map';

const region = {
  latitude: 20.1449858,
  longitude: -16.8884463,
  latitudeDelta: 0.0222,
  longitudeDelta: 0.0321,
};
const otherRegion = {
  latitude: 21.1449858,
  longitude: -12.8884463,
  latitudeDelta: 1.0222,
  longitudeDelta: 2.0321,
};
const coordinate = {
  latitude: 31.788,
  longitude: -102.43,
};
const marker1 = {
  coordinate,
};
const markers = [marker1];
const mapState = fromJS({
  region,
  markers,
});
const initialState = {
  map: mapState,
};
// we are not testing the reducer, so it's ok to have a do-nothing reducer
const reducer = state => state;
// just a mock
const dispatch = jest.fn();
// this is how i mock the dispatch method
const store = {
  ...createStore(reducer, initialState),
  dispatch,
};
const wrapper = shallow(
  <Map store={store} />,
);
const component = wrapper.find(MapComponent);

describe('<Map />', () => {
  it('should render', () => {
    expect(wrapper).toBeTruthy();
  });

  it('should pass the region as prop', () => {
    expect(component.props().region).toEqual(region);
  });

  it('should pass the markers as prop', () => {
    expect(component.props().markers).toEqual(markers);
  });
  // a signal is an action wich will be handled by a saga
  it('should dispatch an newChan signal', () => {
    component.simulate('longPress', { nativeEvent: { coordinate } });
    expect(dispatch.mock.calls.length).toBe(1);
    expect(dispatch.mock.calls[0][0]).toEqual(sNewChan(coordinate));
  });
  // a message is an action wich will be handled by a reducer
  it('should dispatch a setRegion message', () => {
    component.simulate('regionChange', otherRegion);
    expect(dispatch.mock.calls.length).toBe(2);
    expect(dispatch.mock.calls[1][0]).toEqual(mSetRegion(otherRegion));
  });
});

@markerikson 무슨 뜻인가요?

mapStateToProps 구현을 테스트할 수 있습니다

ES6 내보내기를 통해 연결된 컨테이너를 내보내고 있다고 가정해 보겠습니다. 개인 mapStateToProps에 액세스할 수 없습니다. 다른 방식으로 말씀하신 건가요 아니면 구체적으로 말씀해 주실 수 있나요?

@mordrax

속성 이름이 모두 올바른지 확인할 수 있습니다.

따라서 mapStateToProps를 노출하고 공개로 만든 다음 가짜 저장소를 보내고 state prop을 보내는 것을 포함하여 테스트에서 ContainerComponent를 렌더링하면 mapStateToProps가 해당 상태를 수신하고 prop에 매핑합니다. 하지만 그 시점에서 어떻게 그것을 테스트할 수 있습니까? Connect는 mapStateToProps를 호출하여 소품을 병합하지만 이음매는 어디에 있고 프레젠테이션 구성 요소에 설정되는 소품을 가로챌 수 있는 해당 프로세스/흐름 중에 코드의 이음새는 어디입니까? @guatedude2 와 같은 이중 얕음은 이음새 없이 매핑된 소품을 확인하는 한 가지 방법일 수 있습니다...

또한 당신의 shallow.shallow에. 그래서 connect() 구성 요소는 래퍼를 다시 전달합니까? 프레젠테이션 구성 요소를 감싸는 래퍼는 무엇입니까?

@granmoe 가 정확히 무엇을 의미하는지 자세히 설명해 주시겠습니까?

연결에 전달하는 기능에 대한 적용 범위도 있는 경우 구성 요소 전체에 대한 전체 적용 범위가 있어야 합니다.

나는 또한 @tugorez 와 함께 _무엇을_ 테스트하고 싶고 그 이유를 알고 있습니다.

@markerikson 은 스파이에 대한 좋은 예입니다. 테스트할 수 있는 것은 한 가지이지만 "행동 단위"를 테스트하려면 더 많은 검증자가 필요합니다. mapDispatchToProps에서 스파이 작업이 호출되었는지 테스트하는 것만으로는 컨테이너 구성 요소에 대한 전체 내용을 알 수 없습니다. 컨테이너의 처리기 논리를 기반으로 예상되는 결과에 대해 어설션하지 않습니다.

props 또는 state를 통과했는지 테스트하는 것만으로는 충분하지 않으며 컨테이너 구성 요소의 동작을 테스트하고 싶습니다. 이는 두 가지를 테스트하는 것을 의미합니다.

1) 컨테이너 구성 요소가 props를 프리젠테이션 구성 요소에 연결했습니까? 그렇다면 props가 프리젠테이션 구성 요소에 전달한 특정 상태를 기반으로 렌더링되면 프리젠테이션 구성 요소가 가질 것으로 예상하는 특정 상태가 있습니까? 멍청한 개발자가 와서 mapStateToProps에 더 많은 코드를 추가할 수도 있습니다. 항상 올바르게 매핑할 것이라고 믿을 수는 없습니다. 이것이 컨테이너 논리를 테스트하는 요점입니다. mapStateToProps에는 실제로 논리가 없지만 일부 개발자가 다시 와서 거기에 if 문을 광고한다는 것을 알고 있는 사람은... 글쎄, 그것은 일을 엉망으로 만들 수 있는 행동입니다.

2) 디스패치 핸들러 로직(동작)이 컨테이너에서 작동합니까?

@dschinkel :

Redux 연결 구성 요소를 정의하는 일반적인 방법은 export default connect()(MyComponent) 및 export MyComponent 명명된 내보내기입니다. 마찬가지로 mapState 는 함수일 뿐이므로 $# export const mapState = () => {} 를 가져온 다음 별도로 가져오고 테스트할 수도 있습니다.

"컨테이너 구성 요소" 대 "프레젠테이션 구성 요소"를 테스트하는 경우: 여기서 일반적인 생각은 "컨테이너" === "출력"인 경우 대부분의 경우 컨테이너 테스트에 대해 걱정할 필요가 없다는 것입니다. connect ". React-Redux는 이미 그것이 어떻게 작동해야 하는지에 대한 완전한 테스트 스위트를 가지고 있으며 당신이 그 노력을 복제할 이유가 없습니다. 상점 구독, mapState 및 mapDispatch 호출, 래핑된 구성 요소에 소품 전달을 올바르게 처리한다는 것을 _알고_ 있습니다.

라이브러리의 소비자로서 _당신이_ 관심을 가질 것은 _당신의_ 구성 요소가 어떻게 작동하는지입니다. 자신의 구성 요소가 connect 래퍼, 테스트 또는 다른 것으로부터 props를 가져오는지 여부는 실제로 중요하지 않습니다. 특정 props 집합이 주어지면 해당 구성 요소가 어떻게 동작하는지입니다.

(또한, FWIW, 나는 당신이 테스트에 대한 절대적으로 전문가라는 것을 알고 저는 그렇지 않습니다. 그러나 당신이 사물에 대해 약간 편집증을 느끼고 있는 것 같습니다 _does_): mapState 에 대해 걱정한다면 실수로 깨진 다음 테스트를 작성하고 계속 진행하십시오.)

이제 래핑된 구성 요소가 내부에 연결된 다른 구성 요소를 렌더링하고 특히 얕은 렌더링 대신 전체 렌더링을 수행하는 경우 const wrapper = mount(<Provider store={testStore}><MyConnectedComponent /></Provider> 를 수행하여 테스트하는 것이 훨씬 더 간단할 수 있습니다. 그러나 전반적으로 내 생각은 대부분의 경우 mapState 기능과 "일반" 구성 요소를 별도로 테스트할 수 _ 있어야 _ 해야 하며, 단지 확인을 위해 연결된 버전을 테스트하려고 해서는 안 된다는 것입니다. mapState 의 출력이 일반 구성 요소로 전달되고 있습니다.

참고로 Dan이 내부적으로 수행하는 작업을 설명하기 위해 얼마 전에 작성한 connect 의 축소 버전을 볼 수 있습니다. https://gist.github.com/gaearon/1d19088790e70ac32ea636c025ba424e .

예, mapStateToProps 및 dispatchStateToProps를 내보내면 더 좋을 것입니다. 나는 connect()(내 테스트의 공동 작업자)가 작동하는지 테스트하고 싶지 않습니다 . 그렇게 하는 한 가지 분명한 방법이 될 것이므로 다음 두 가지 방법을 내보냅니다.

example-container-spec.js

describe('testing mapPropsToState directly', () => {
    it.only('returns expected state', () => {
        const state = {firstName: 'Dave'};
        const output = mapStateToProps(state);

        expect(output.firstName).to.equal('Dave');
    });
});

컨테이너

import React from 'react';
import { connect } from 'react-redux'
import Example from './Example';

export const mapStateToProps = (state) => ({
    firstName: state.firstName
})

export default connect(mapStateToProps)(Example);

프레젠테이션

import React, { Component } from 'react';

export default class Example extends Component {
    render(){
        return (
            <div className='example'>
                {this.props.firstName}
            </div>
        )
    }
}

그런 다음 다시 _shallow_ 렌더링을 사용하여 이와 같은 작업을 수행하고 여전히 하위 구성 요소로 다이빙할 수 있습니다.

example-container-spec.js

it('persists firstName to presentation component', () => {
        var state = {firstName: "Dave"};
        const container = mount(<ExampleContainer store={fakeStore(state)}/>),
            example = container.find(Example);

        expect(example.length).to.equal(1);
        expect(example.text()).to.equal(state.firstName);
    });

컨테이너

import React from 'react';
import { connect } from 'react-redux'
import Example from './Example';

const mapStateToProps = (state) => ({
    name: state.firstName
})

export default connect(mapStateToProps)(Example);

프레젠테이션

import React, { Component } from 'react';

export default class Example extends Component {
    render(){
        return (
            <div className='example'>
                {this.props.firstName}
            </div>
        )
    }
}

이것을 얕게 하는 또 다른 방법은 이중 얕게 하는 것입니다. 얕은 부모의 얕은 것은 다음과 같이 래핑되는 자식 구성 요소를 얕은 것입니다.

it('get child component by double shallow()', () => {
        const container = shallow(<ExampleContainer store={fakeStore({})}/>),
            presentationalChildComponent = container.find(Example).shallow().find('.example');

        expect(presentationalChildComponent).to.have.length(1);
    });

따라서 프레젠테이션 구성 요소의 결과를 확인하는 또 다른 방법입니다.

어느 쪽이든 작동할 수 있습니다. 그러나 prop 상태 설정 측면에서 테스트하는 데 관심이 있는 것은 mapStateToProps를 내보내는 것이 가장 좋습니다.

나는 당신이 테스트의 절대적으로 전문가이고 나는 그렇지 않다는 것을 알고 있지만, 당신이 사물에 대해 약간 편집증을 느끼는 것 같습니다 :)

아닙니다. 올바른 테스트는 깨지지 않고 가치를 제공하는 좋은 테스트를 갖는 것이 중요합니다. 우선 아무도 _전문가_가 아닙니다. 모든 사람은 계속해서 배우고 있으며 일부는 자존심 때문에 그것을 인정하고 싶지 않습니다. 소프트웨어 장인 정신(일명 전문성)이라고 합니다.

당신이 말했듯이 행동 만 테스트하고 협력자 (connect() 자체)를 테스트하지 않는 것이 중요합니다. 처음으로 그것을 파악하고 잘 테스트하는 것이 중요합니다. 공동 작업자를 테스트하지 않는지 확인하는 것이 중요하며 때로는 동료 개발자 간의 토론이 필요합니다.

취성 테스트를 할 수 있으며 취성 테스트를 하지 않는 것이 중요합니다. 테스트는 진지하게 받아들여야 하며, 이는 테스트에 올바르게 접근하고 있는지 지속적으로 확인해야 함을 의미합니다. 나는 단지 내 흐름을 파악하려고 노력하고 있습니다. I TDD, 그래서 시작하는 방법이 중요하고 좋은 테스트가 중요합니다. 따라서 아무도 React 구성 요소를 테스트하는 다양한 방법을 이해하려고 할 때 "편집증"이라고 느끼지 않아야 합니다.

새로운 React 테스트 리포지토리 출시 중...
실제로 react-redux 테스트에 대한 다양한 스타일과 조합 및 접근 방식을 보여주는 리포지토리를 곧 공유할 예정입니다. 나는 이것에 대해 생각하는 유일한 사람이 아니기 때문에 그것이 사람들에게 도움이 될 것이라고 생각합니다. 사람들이 redux 컨테이너 및 기타 구성 요소를 테스트하는 것과 관련하여 동일한 질문을 하는 것을 몇 번이고 보게 됩니다. Redux 문서나 react-redux 문서는 이에 대해 정의를 내리지 않으며 IMO 테스트 영역에 문서가 부족합니다. 그것은 단지 표면을 긁는 것일 뿐이며 React 테스트에 접근하는 방법에 대한 다양한 스타일을 보여주는 멋진 저장소가 필요하므로 곧 올리도록 하겠습니다.

If anyone would like to contribute to that repo, please get a hold of me 귀하를 공동 작업자로 추가할 수 있습니다. 사람들이 예를 추가했으면 합니다. 나는 Enzyme , Ava , Jest , tape 등이 포함된 React Test Utils + mocha 를 사용한 예제를 보고 싶습니다.

결론 :

우리가 논의한 두 가지 접근 방식이 모두 괜찮다고 생각합니다. 방법을 직접 테스트하거나 위에서 했던 것처럼 테스트해 보세요. 때로는 취약한 테스트를 받을 수 있기 때문에 특정 방법에 기반한 테스트를 하고 싶지 않을 때가 있습니다. 따라서 하나의 기능을 테스트할지 여부는 "단위"를 테스트하는지 여부에 따라 다릅니다. 때로는 메소드를 공개하고 싶지 않을 때가 있는데, 그 위의 계약을 테스트하고 일부를 비공개로 유지하는 것이 더 나을 수 있습니다. 따라서 테스트를 작성할 때 자주 무엇을 하는지 생각하는 것이 항상 중요합니다. 문제가 없습니다. 좋은 테스트를 작성하는 것은 쉽지 않습니다.

그것이 바로 TDD가 촉진하는 것입니다. 자주 하는 것입니다. 따라서 더 간결하고 덜 깨지기 쉬운 코드로 끝납니다. TDD는 나중에가 아니라 미리 테스트에 대해 생각하도록 합니다. 그것이 바로 차이점이며 나와 같은 사람들이 다른 흐름과 접근 방식을 이해하기를 원하는 이유는 내가 TDD를 할 때 디자인을 자주 작은 덩어리로 재평가해야 하기 때문입니다. 즉, 테스트 접근 방식에 대해 자주 생각해야 한다는 의미입니다.

@markerikson 입력해 주셔서 감사합니다. 테스트에 대해 이야기하는 것을 좋아합니다. 좋은 물건 남자. 나는 당신의 전문 지식에 의문을 제기한 것이 아니라 실제로 직접 mapStateToProps 테스트를 시도하지 않았다는 것입니다! 테스터가 아닌 것이 나쁜 것은 아닙니다 ;). 저는 단순히 redux를 처음 접했을 뿐이므로 "표면에 닿는 것"이 ​​아닌 질문이 있을 것입니다. 사람들이 자신이 하는 일, 수행 방법, 접근 방식의 이점을 이해할 수 있도록 낮은 수준에서 테스트에 대해 논의해야 합니다. 그렇게 하려면 "동작만 테스트"하는 방법을 알 수 있도록 낮은 수준의 connect, react-redux, provider를 이해해야 합니다. 나에게도 흥미로운 mapStateToProps를 내보내는 사람들을 많이 보지 못했습니다. 왜 안 되는지 궁금합니다.

WeDoTDD.com
관심 있는 분들을 위해 작년에 WeDoTDD.com 을 시작했습니다(React btw로 작성). 특정 팀(특정 팀의 모든 개발자) TDD 또는 회사 전체(일부 회사에는 모든 TDD, 특히 컨설팅 회사에 개발자가 있는 경우)가 있는 경우 slack.wedotdd.com 에서 저에게 연락하십시오.

업데이트.

연결된 구성 요소를 더 많이 테스트하고 나에게 잘 작동하는 것이 무엇인지 반영한 후 여기 @markerikson 의 진술에 100% 동의합니다.

실제로 연결된 구성 요소를 테스트해야 한다고 생각되면 다음을 렌더링할 수 있어야 합니다. 제공자나 컨텍스트 등에 대해 걱정할 필요가 없습니다.

나는 내 테스트에 <Provider /> 를 도입할 필요를 보지 못했고 <Provider /> 가 작동하는지 테스트하는 것이 요점이 아닐 때 그렇게 하면 공동 작업자를 테스트하는 것처럼 보입니다. 구성 요소의 동작이 작동하는지 테스트해야 하며 컨테이너가 컨텍스트를 통해 저장소를 가져오는지 여부는 중요하지 않습니다. 상점을 소품으로 전달하기만 하면 됩니다. 연결은 상점에 도달하기 위한 어떤 방법이 필요합니다. 테스트에서 공급자를 완전히 제거하는 방법(컨텍스트 또는 소품)은 상관하지 않습니다.

또한 React의 컨텍스트를 통해 저장소를 유지할 수 있는 또 다른 방법인 enzyme의 컨텍스트 옵션을 사용할 필요가 없습니다. 테스트에서 반응의 컨텍스트를 모두 잊어버리십시오. 완전히 불필요한 팽창이며 테스트를 더 복잡하고 유지 관리하고 읽기가 훨씬 더 어렵게 만듭니다.

mapStateToProps 순수 함수를 컨테이너 파일로 내보내 직접 테스트하십시오. 나는 mapStateToProps 테스트의 콤보를 사용하고 있으며 내 컨테이너를 얕게 테스트하는 몇 가지 테스트를 사용하고 있습니다. 프리젠테이션 구성 요소가 최소한 내가 예상하는 props를 수신하고 있는지 확인한 다음 props 테스트로 중지합니다. 또한 컨테이너 구성 요소 테스트를 위해 이중 얕은 작업을 수행하지 않기로 결정했습니다. TDD는 그렇게 하려고 하면 테스트가 너무 복잡해지고 아마도 뭔가 잘못하고 있다는 피드백을 주고 있습니다. 그 "잘못된 것"은 "컨테이너 구성 요소 테스트를 위해 얕은 것을 두 배로 늘리지 마십시오"입니다. 대신 프레젠테이션 구성 요소의 출력을 독립적으로 테스트하는 프레젠테이션 구성 요소 테스트의 새 모음을 만듭니다.

일이 잘 풀렸다니 다행입니다. (FWIW, 내 의견은 "이음새" 및 "소도구 파고들기"에 대한 귀하의 질문에 대한 답변이었습니다. 실제로 거의 또는 전혀 도움이 되지 않는 불필요한 세부 수준으로 가는 것처럼 보였습니다.)

연결된 다른 구성 요소를 렌더링하는 구성 요소의 전체 렌더링을 수행하는 경우 <Provider> /context _is_ 를 사용하는 것이 필요할 것입니다. 연결된 자식이 컨텍스트에서 저장소를 찾을 것이기 때문입니다.

테스트에서 Redux의 현재 문서를 개선하기 위한 제안이 있으면 반드시 PR을 제출하십시오.

@markerikson 마운트의 좋은 점. 테스트 중인 구성 요소의 수명 주기를 테스트해야 하는 경우에만 마운트를 수행합니다. 더 이상 단위 테스트로 적합하지 않고 기본적으로 통합 테스트이므로 하위 구성 요소에 대해 자세히 알아보는 데 사용하지 않을 것입니다. 상위 구성 요소를 통하지 않고 개별적으로 소유합니다.

아무튼 좋은 자료 감사합니다!

맞습니다. mount 를 사용하여 해당 구성 요소의 수명 주기를 확인하고 해당 구성 요소가 연결된 다른 구성 요소를 렌더링하는 경우 다음과 같은 경우 오류를 방지하기 위해 중첩된 구성 요소에 대한 컨텍스트에서 사용 가능한 저장소가 _필요_합니다. 테스트 중인 구성 요소가 렌더링됩니다.

(편집: 나는 분명히 나 자신을 반복하고 있는 것 같습니다. 죄송합니다. 항상 스레드를 통해 돌아가지 않고 심지어 약간 위로 스크롤하지 않고도 여러 장소에서 질문에 대답하는 위험이 있습니다.)

아 알았어! 네 그건 생각을 못했네요...

@markerikson 및 @dschinkel의 모든 의견에 감사드립니다! 그들은 매우 도움이됩니다. 이제 연결되지 않은 구성 요소를 내보내고 다른 구성 요소와 마찬가지로 테스트하고 mapStateToProps 및 mapDispatchToProps 도 별도로 테스트하기로 결정했습니다. 그러나 이러한 테스트가 포착하지 못하는 한 가지 경우가 있는데, map(State/Dispatch)ToProps 가 실제로 connect 에 대한 호출로 전달되지 않는 경우입니다. 예시:

import React from 'react';
import { connect } from 'react-redux';

export const mapStateToProps = ({ name }) => ({ name });

export const Example = ({ name }) => <h1>{name}</h1>;

export default connect({ name } => ({ name: firstName }))(Example); // Whoops, didn't actually pass in `mapStateToProps`.

이것은 아마도 실제로 발생하지 않을 것입니다. 그러나 특히 linters가 mapStateToProps 를 내보내는 동안 사용하지 않은 변수로 보고하지 않기 때문에 발생할 수 있습니다.

@danny-andrews mapDispatchToProps 기능을 테스트하는 방법에 대해 더 구체적으로 말씀해 주시겠습니까?

@leizard

더 이상 mapDispatchToProps 또는 mapStateToProps를 직접 테스트하지 않습니다. 이 스레드 이후로 마음이 바뀌었고 그렇게 하지 말라고 조언합니다.

또한 테스트하면 @danny-andrews 문제가 발생하지만 문제는 좋은 테스트에 관한 것이며 이 두 기능을 노출하려는 것은 좋은 생각이 아닙니다. 테스트가 끝났습니다. 동작을 테스트하거나 얕은 컨테이너를 통해 소품을 테스트하여 이 두 가지 방법을 간접적으로 테스트해야 합니다. 나는 그러한 개인 메서드를 노출하려고 할 이유가 없다는 것을 알았고 이제 그렇게 하려고 시도하는 것도 나쁜 테스트 관행이라는 것을 깨달았습니다.

그래서 나는 @markerikson 에 동의하지 않습니다. 연결된 구성 요소를 통해 테스트하십시오.

오버 테스트가 아닌 테스트에 적합한 API/계약을 찾는 것이 핵심입니다. :).

@dschinkel

동작을 테스트하여 이 두 가지 방법을 간접적으로 테스트해야 합니다...
그래서 나는 @markerikson 에 동의하지 않습니다. 연결된 구성 요소를 통해 테스트하십시오.

연결되지 않은 구성 요소를 완전히 내보내고 연결된 구성 요소만 테스트해야 한다고 제안하고 있습니까? 나는 그것이 "오버 테스트"라고 생각 합니다 . 이는 테스트를 테스트 중인 구성 요소의 구현 세부 정보에 불필요하게 연결합니다. 연결되지 않은 구성 요소의 기능(있는 경우 완전히 다른 웜 수 있음)은 props를 받는 위치와 완전히 관련이 없습니다. 나중에 해당 구성 요소를 순수한 프레젠테이션 구성 요소로 전환하고 싶을 수도 있습니다. 연결된 구성 요소를 테스트하는 경우 더 이상 저장소를 삽입하지 않고 소품을 직접 전달하도록 모든 테스트를 변경해야 합니다. 연결되지 않은 구성 요소를 테스트했다면 연결된 구성 요소별 테스트를 날려 버리는 것 외에는 아무 것도 할 필요가 없습니다(자세한 내용은 아래 참조).

하지만 mapStateToProps / mapDispatchToProps 를 직접 테스트해서는 안 된다는 데 동의합니다. 단순히 테스트 목적으로 이러한 개인 메서드를 노출하는 것은 나에게 항상 코드 냄새처럼 느껴졌습니다. 사실, 연결된 구성 요소를 테스트해야 하는 유일한 시간이라고 생각합니다. 요약하자면:

1. 연결되지 않은 구성 요소 및 연결된 구성 요소 내보내기
2. mapStateToProps 또는 mapDispatchToProps 수출 금지
3. 연결되지 않은 구성 요소를 통해 모든 구성 요소 논리 테스트
4. redux와의 상호 작용을 테스트할 때 연결된 구성 요소만 테스트합니다(store/action props의 적절한 위치에서 데이터 props가 적절한 action 작성자에게 할당됨).

4번을 수행할 때의 유일한 추가 오버헤드는 연결된 구성 요소에 전달하기 위해 redux 저장소를 제거해야 한다는 것입니다. 하지만 API가 세 가지 방법에 불과하기 때문에 이것은 매우 쉽습니다.

MapStateToProps 메서드

TestContainer.jsx:

import { connect } from 'react-redux';

export const TestContainer = ({ permissions }) => (permissions['view-message'] ? 'Hello!' : null);

export const mapStateToProps = ({ auth }) => ({ permissions: auth.userPermissions });

export default connect(mapStateToProps)(TestContainer); // Ewww, exposing private methods just for testing

TestContainer.spec.jsx:

import React from 'react';
import { shallow } from 'enzyme';

import TestContainer, { mapStateToProps } from './TestContainer';

it('maps auth.userPermissions to permissions', () => {
  const userPermissions = {};

  const { permissions: actual } = mapStateToProps({
    auth: { userPermissions },
  });

  expect(actual).toBe(userPermissions);
});

새로운 방법

TestContainer.jsx:

import { connect } from 'react-redux';

export const TestContainer = ({ permissions }) => (permissions['view-message'] ? 'Hello!' : null);

const mapStateToProps = ({ auth }) => ({ permissions: auth.userPermissions });

export default connect(mapStateToProps)(TestContainer);

TestContainer.spec.jsx:

import React from 'react';
import { shallow } from 'enzyme';

import TestContainer, { TestComponent } from './TestContainer';

it('renders TestComponent with approriate props from store', () => {
  const userPermissions = {};
  // Stubbing out store. Would normally use a helper method. Did it inline for simplicity.
  const store = {
    getState: () => ({
      auth: { userPermissions },
    }),
    dispatch: () => {},
    subscribe: () => {},
  };
  const subject = shallow(<TestContainer store={store} />).find(TestComponent);

  const actual = subject.prop('permissions');
  expect(actual).toBe(userPermissions);
});

예, mapStateToProps를 내보내고 테스트하지 않고 테스트 가 끝났습니다. API 를 통해 테스트합니다. API는 Container 입니다.

@danny-andrews

연결되지 않은 구성 요소를 통해 모든 구성 요소 논리 테스트

몇 가지 예를 들 수 있습니까?

나는 당신이 말한 것과 같은 것을 의미합니다. "행동을 테스트하여 두 가지 방법을 간접적으로 테스트해야합니다."

용어를 명확히 하는 것이 도움이 될 수 있습니다. "연결되지 않은 구성 요소"라고 할 때 connect 에 대한 호출에 래핑된 원시 구성 요소를 의미하고 "연결된 구성 요소"라고 말할 때는 다음에서 반환되는 결과 구성 요소를 의미합니다. connect 에 대한 호출 "연결된 구성 요소"와 "컨테이너"는 동의어라고 생각합니다. 내 위에서 :

// Unconnected component. Test all component logic by importing this guy.
export const TestComponent = ({ permissions }) => (permissions['view-message'] ? 'Hello!' : null);

const mapStateToProps = ({ auth }) => ({ permissions: auth.userPermissions });

// Connected component (container). Only test interaction with redux by importing this guy.
export default connect(mapStateToProps)(TestComponent);

어떤 사람들은 이것들을 완전히 분할하고 "컨테이너"가 순전히 프레젠테이션 구성 요소를 래핑하는 connect 에 대한 호출로 사용하는 것을 선호합니다. 이 경우 목록의 1번과 3번은 사라지고 작성해야 하는 테스트는 redux(4번)와의 상호 작용을 확인하는 테스트뿐입니다.

나는 이것에 대한 거대한 블로그 게시물을 작성할 계획입니다. 지금은 코드로 바쁘지만 나중에 답장하겠습니다.

이 스레드를 여러 번 읽은 후 권장되는 3가지 접근 방식이 있다는 결론에 도달했습니다.

1. mapDispatchToProps 및 mapStateToProps 내보내기 및 별도로 테스트
2. 컨테이너 구성 요소를 얕게 렌더링하고 배선이 올바른지 테스트합니다.
3. mapStateToProps 대신 선택자를 사용하고 mapDispatchToProps 대신 액션 작성자를 사용하고 별도로 테스트하십시오. 전체 흐름이 작동하는지 확인하기 위해 작업 생성자, 감속기 및 선택기를 함께 사용하여 테스트를 작성합니다.

결국 모든 옵션이 유효하지만 장단점이 있다고 생각합니다. "가장 순수한" 것은 아마도 두 번째 것일 수 있지만 대부분의 작업도 포함합니다. 내 개인적인 취향은 실제로 옵션 3으로 갈 것입니다.
내 블로그 에 이에 대해 더 자세히 썼습니다. 여기에는 몇 가지 코드 샘플도 있습니다.

@ucorina
ES6 모듈의 현재 세계에서 각 파일은 자체 범위에 래핑된 모듈로 간주됩니다. 내보내기는 작은 모듈의 API이며 테스트할 수 있도록 메서드를 내보내는 것은 매우 잘못된 일입니다. 테스트를 위해 비공개 메서드를 공개하는 방법과 비슷합니다.

이것이 내가 @dschinkel 접근 방식을 선호하고 mapDispatch 및 mapState를 내보내지 않는 이유입니다. 왜냐하면 그들은 연결된 구성 요소의 비공개 구현이기 때문입니다.

그러나 연결 주위에 다른 구성 요소만 래핑하는 구성 요소로 무엇을 해야 할지 잘 모르겠습니다.

블로그 게시물을 작성한 적이 있습니까? @dschinkel 은 그것을 읽고 싶어합니다.

@AnaRobynn

예, mapDispatch 및 mapState 를 내보내는 것 자체가 잘못된 느낌이 든다는 데 동의합니다. 직접 사용하지는 않을 것입니다. 그러나 덜 "순수한" 옵션이더라도 유효한 옵션입니다. . Dan Abramov가 https://github.com/reduxjs/react-redux/issues/325#issuecomment -199449298에서 이 정확한 기술을 제안했기 때문에 가능한 옵션으로 남겨 두었습니다.

"연결 주위에 다른 구성 요소만 래핑하는 구성 요소로 무엇을 할 것인가"에 대한 귀하의 질문에 대답하려면 테스트하지 말라고 말하고 싶습니다. 애플리케이션과 관련된 비즈니스 로직이 없고 connect 구현을 테스트하고 싶지 않습니다. 이는 이미 react-redux 라이브러리에서 테스트되었습니다.

그래도 테스트를 하고 싶으시다면 나중에 코드를 증명하기 위해 @dschinkel 이 설명하는 내용에 더 가까운 여기에서 설명하는 두 번째 접근 방식을 항상 따를 수 있습니다.

@ucorina 맞아요, 옵션도 제가 가고 싶은 것 같아요! 답변을 더 자세히 설명해 주셔서 감사합니다. 잘 쓴 블로그 글입니다. 축하해!

@ucorina 다시 귀찮게 해서 죄송합니다. 그러나 잠시 동안 자고 나면 옵션 2에도 완전히 동의하는지 확신할 수 없습니다. 확실하지 않습니다. 나는 또한 mapStateToProps를 테스트하는 것의 이점에 대해 전혀 확신하지 못합니다.

'옵션 2'가 액션 제작자를 간접적으로 테스트하는 것도 괜찮다고 보십니까? 또한 간접적으로 선택기를 테스트합니까? 좋은 일이야?
나는 그것에 대해 100% 확신할 수는 없지만 거기에 있는 모든 (잘못된) 정보에 대해서도 혼란스럽습니다. 테스트에 대한 다양한 아이디어가 있습니다.

1. mapStateToProps 내부의 선택기만 사용
   
   
   
   • 필요한 경우 컨테이너 테스트 중에 조롱하십시오.
   
   
   • 선택기를 별도로 테스트하십시오.
   
   
   • mapDispatchToProps 내에서 액션 생성자만 사용
   
   
   • 필요한 경우 컨테이너 테스트 중에 조롱하십시오.
   
   
   • 작업 생성자를 별도로 테스트합니다.
   
   
   • 얕은 연결 구성 요소
   
   
   • 렌더링되었다고 주장
   
   
   • mapStateToProps , mapDispatchToProps 또는 mergeProps 에 추가해야 하고 다른 곳에서는 아직 테스트되지 않은 추가 논리를 테스트합니다. (조건부 디스패치, ownProps 에서 인수를 받는 선택기 등)
     
     
     
     
     
     • 이 경우 올바른 시간과 올바른 인수를 사용하여 모의 객체가 호출되었는지 테스트하는 것뿐입니다.
     
     
     
   
   

대안:

• 컨테이너 + 선택기를 함께 테스트하기 위한 모의 저장소 상태
• 컨테이너 + 작업을 함께 테스트하기 위해 외부 API 호출 모의

@AnaRobynn @ucorina 의 두 번째 접근 방식이 올바른 접근 방식이라고 생각합니다.

내가 들은 많은 것은 다음과 같습니다.

1. mapDispatchToProps를 노출하고 직접 테스트해야 합니다.
2. connect()가 이미 테스트되었으므로 connect()에 대한 호출을 테스트할 필요가 없습니다.

1과 관련하여 테스트를 위해 내부를 노출하는 것은 좋은 방법이 아니라고 생각합니다. 테스트 A: 이제 내부 구조를 가정하고 B: 실제로 사용되는 방식을 테스트해야 합니다.

2에 관해서는 _절대적으로_ 외부 라이브러리를 호출하는 것을 테스트해야 합니다. 이것은 깨는 응용 프로그램의 약점 중 하나입니다. 모든 라이브러리에서 마이너/패치 버전 범프에 주요 변경 사항이 도입될 수 있으며 테스트가 빨리 실패하기를 _원합니다_.

'옵션 2'가 액션 제작자를 간접적으로 테스트하는 것도 괜찮다고 보십니까? 또한 간접적으로 선택기를 테스트합니까? 좋은 일이야?

예, 중복 테스트 커버리지는 좋은 것입니다.

@philihp @dougbacelar
나는 React 애플리케이션 테스트와 관련하여 조금 성장했다고 생각합니다. 나의 현재 신념과 주제에 대한 생각:

1. 여러 구성 요소에서 이러한 매핑이 필요하지 않은 경우 mapStateToProps 및 mapDispatchToProps 를 노출하지 마십시오. 테스트용으로만 내보내는 것은 반패턴입니다.
2. 저는 현재 컨테이너를 협력자(다른 기능을 위임하는 기능과 실제 논리를 수행하는 다른 기능)로 봅니다.
   그게 무슨 뜻이야?
3. 컨테이너는 어떤 논리도 수행하지 않습니다.
4. 상태를 선택하는 논리는 선택기 기능을 위한 것입니다(순전히 단위 테스트 가능).
5. 액션에 대한 논리는 액션 생성자에 숨겨져 있습니다(redux-thunk를 사용하는지 여부에 따라 그 자체로 공동 작업자가 될 수 있음)
6. 렌더링된 뷰는 다른 기능입니다(잠재적으로 다른 협력자 기능이 있거나 순수하게 물건을 렌더링합니다.

=> 적절한 테스트 라이브러리를 사용할 때 테스트 설정은 실제로 매우 간단합니다(testdouble.js 권장).
=> testdouble.js를 통해 선택기와 작업을 조롱하십시오( td.when() 사용).
=> 컨테이너 구성 요소를 얕게 렌더링하고 뷰 구성 요소의 메서드에 액세스하기 위해 dive() 한 번
=> td.when() 의 규칙 세트가 주어지면 구성 요소가 올바르게 작동하는지 확인

약간의 fakeStore 라이브러리를 주입할 필요가 없습니다. 저장소를 스텁 아웃하는 것이 좋습니다.

예시:

/** <strong i="27">@format</strong> */

import React from 'react';
import { shallow } from 'enzyme';

function setup(props) {
  const HasOrganization = require('./HasOrganization').default;
  const defaultProps = {
    store: {
      subscribe: Function.prototype,
      getState: Function.prototype,
      dispatch: Function.prototype,
    },
  };
  const container = shallow(<HasOrganization {...defaultProps} {...props} />);
  return {
    container,
    wrapper: container.dive(),
  };
}

describe('<HasOrganization /> collaborations', () => {
  let getCurrentOrganizationId;
  beforeEach(() => {
    getCurrentOrganizationId = td.replace('../containers/App/userSelectors')
      .selectCurrentOrganizationId;
  });

  test('not render anything when the id is not valid', () => {
    const Dummy = <div />;
    td.when(getCurrentOrganizationId()).thenReturn(null);
    const { wrapper } = setup({ children: Dummy });

    expect(wrapper.find('div').length).toBe(0);
  });

  test('render something when the id is valid', () => {
    const Dummy = <div />;
    td.when(getCurrentOrganizationId()).thenReturn(1);
    const { wrapper } = setup({ children: Dummy });

    expect(wrapper.find('div').length).toBe(1);
  });
});

생각?

@AnaRobynn 1번과 2번 항목에 전적으로 동의합니다!

내 컨테이너는 일반적으로 매우 간단합니다.

// imports hidden

const mapStateToProps = (state, { userId }) => ({
  isLoading: isLoading(state),
  hasError: hasError(state),
  placeholders: getPlaceholders(userId)(state), // a list of some sort
  shouldDoStuff: shouldDoStuff(state),
});

const mapDispatchToProps = {
  asyncActionPlaceholder,
};

export const mergeProps = (stateProps, dispatchProps, ownProps) => {
  return {
    ...stateProps,
    ...dispatchProps,
    ...ownProps,
    onMount: () => {
      if (stateProps.shouldDoStuff) {
        dispatchProps.asyncActionPlaceholder(ownProps.userId);
      }
    },
  };
};

export default compose(
  connect(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps
  ),
  callOnMount(props => props.onMount())
)(SampleComponent);

그래서 나는

1. 모든 선택자와 작업 생성자를 감시하십시오.
2. 테스트 getPlaceholders 스파이가 올바른 userId로 호출되었습니다.
3. SampleComponent 가 올바른 소품으로 렌더링되었다고 주장합니다.
4. SampleComponent onMount shouldDoStuff===true 때 모의 작업을 전달하는지 확인합니다.

• SampleComponent 에 대한 별도의 테스트에서 테스트할 props에 따라 항목의 조건부 렌더링과 같은 것
• 나는 또한 configureMockStore([thunk])() 와 같은 상점을 조롱하기 위해 redux-mock-store 를 사용하는 것을 선호하지만 그렇게 하지 않는 것이 좋다고 생각합니다...

TL, DR 기본적으로 테스트 선택기만 올바른 인수로 호출되었고, 모의 작업이 성공적으로 전달되었으며(어떤 논리에 의존하는 경우) 하위 구성 요소가 올바른 props로 렌더링되었는지 확인합니다.

@philihp

• 나는 외부 라이브러리를 테스트하는 것을 매우 반대하며 모든 것을 조롱하고 개별적으로 테스트하는 것을 선호합니다.
• 엔드 투 엔드 테스트가 라이브러리 업그레이드로 인해 발생하는 모든 주요 문제를 찾아낼 것이라고 확신합니다.
• 내가 컨테이너+선택기+액션 생성기를 모두 함께 테스트하는 것을 좋아하지 않는 이유는 재사용하는 다른 모든 컨테이너에 대해 동일한 선택기와 액션 생성기를 다시 테스트해야 하기 때문입니다. 그 시점에서 단위 테스트 자체에 더 많은 테스트 케이스를 추가하는 것이 좋습니다.

@dougbacelar 당신이 보여준 구성 요소를 테스트하기 위해 몇 가지 샘플 테스트 코드를 제공할 수 있습니다. 효소를 사용하고 있습니까? 다른 것? 얕은? 산?

@dougbacelar

나는 외부 라이브러리를 테스트하는 것을 매우 반대하며 모든 것을 조롱하고 개별적으로 테스트하는 것을 선호합니다.

필요할 때 조롱하지만 실제를 사용할 수 있다면 그 이유는 무엇입니까? 조롱은 특정 호출이 느리거나 네트워크 요청과 같은 부작용이 있을 때 유용합니다.

내가 컨테이너+선택기+액션 생성기를 모두 함께 테스트하는 것을 좋아하지 않는 이유는 재사용하는 다른 모든 컨테이너에 대해 동일한 선택기와 액션 생성기를 다시 테스트해야 하기 때문입니다. 그 시점에서 단위 테스트 자체에 더 많은 테스트 케이스를 추가하는 것이 좋습니다.

예 , 선택자, 작업 작성자를 독립적으로 테스트하십시오. 많은 예상 입력으로 철저히 테스트하십시오.

예 , 컨테이너도 테스트하십시오. 그것이 선택자와 작업 생성자에 대해 중복되는 적용 범위를 제공한다는 것을 의미한다면 그것은 나쁜 것이 아닙니다.

여기 내 말은 ...

import React from 'react';
import PropTypes from 'prop-types';
import { connect } from 'react-redux';
import { saveColor } from '../actions/save';
import { selectColors } from '../reducers/colors.js';
import ColorButtons from '../components/ColorButtons';
const ColorButtons = ({ colors, onClick }) => (
  <div>
    {colors.map(color => {
      <button type="button" key={color} onClick={onClick(color)}>{color}</button>
    })}
  </div>
);
ColorButtons.propTypes = {
  colors: PropTypes.arrayOf(PropTypes.string),
  onClick: PropTypes.func.isRequired,
};
const mapStateToProps = state => ({
  colors: selectColors(state.colors),
});
const mapDispatchToProps = dispatch => ({
  onClickColor: color => () => {
    dispatch(saveColor({ color }));
  },
});
export default connect(
  mapStateToProps,
  mapDispatchToProps
)(ColorButtons);

import React from 'react';
import { shallow } from 'enzyme';
import configureStore from 'redux-mock-store';
import ColorButtons from '../ColorButtons';
import { saveColor } from '../../actions/save';
import { selectColors } from '../../reducers/colors.js';
const buildStore = configureStore();
describe('<ColorButtons />', () => {
  let store;
  let wrapper;
  const initialState = { colors: ['red', 'blue'] };
  beforeEach(() => {
    store = buildStore(initialState);
    wrapper = shallow();
  });
  it('passes colors from state', () => {
    expect(wrapper.props().colors).toEqual(selectColors(initialState.colors));
  });
  it('can click yellow', () => {
    const color = 'yellow';
    wrapper.props().onClick(color)();
    expect(store.getActions()).toContainEqual(saveColor({ color }));
  });
});

여기서 이것은 selectColors 및 saveColor 가 얻을 수 있는 모든 다른 매개변수를 테스트하는 것이 아닙니다. <ColorButtons /> 가 생성될 때 얻을 것으로 기대하는 속성을 가져오는지 테스트하고 있습니다. 다른 테스트에서 절대적으로 테스트하십시오.

import { selectColors } from '../colors.js';
describe('selectColors', () => {
  it('returns the colors', state => {
    expect(selectColors(['red'])).toEqual(['red'])
  })
  it('returns an empty array if null', state => {
    expect(selectColors(null)).toEqual([])
  })
  it('returns a flattened array', state => {
    expect(selectColors(['red', ['blue', 'cyan']])).toEqual(['red','blue','cyan'])
  })
})

나는 외부 라이브러리를 테스트하는 것을 매우 반대하며 모든 것을 조롱하고 개별적으로 테스트하는 것을 선호합니다.

필요할 때 조롱하지만 실제를 사용할 수 있다면 그 이유는 무엇입니까? 조롱은 특정 호출이 느리거나 네트워크 요청과 같은 부작용이 있을 때 유용합니다.

부분적으로는 동의하지 않습니다.
나는 외부 라이브러리를 조롱하지 않습니다(자신이 소유하지 않은 것을 조롱하지 마십시오). 하지만 axios와 같은 래퍼를 작성합니다. 협업 테스트에서 모든 기능을 조롱하고 모든 것이 올바르게 연결되었는지 확인할 수 있습니다.

내 협업 테스트에서 나는 항상 모듈, 기능 등을 조롱합니다.
공동 작업자가 호출한 이러한 함수는 쉽게 단위 테스트할 수 있습니다.

여기 내 말은 ...

또한 동의하지 않습니다.
여기에서 감속기와 선택기를 암시적으로 테스트하고 있습니다. 그것이 당신이 잘하고 싶은 것이지만 나는 이러한 함수를 조롱하고 올바르게 호출되는지 확인하는 것을 선호합니다. 나머지는 감속기/선택기에 의해 처리됩니다.

이 스레드는 https://martinfowler.com/articles/mocksArentStubs.html , Classical and Mockist Testing 에서 만든 포인트를 다시 해싱합니다.

동의. 잠금.