Redux: जुड़े घटकों का परीक्षण करना, जिनके भीतर जुड़े हुए घटक निहित हैं

दो चीज़ें:

1) यह उपयोग है और शायद अतिप्रवाह ढेर करने के लिए जाना चाहिए।

2) connect उच्च आदेश घटक का उपयोग करने की सुविधा का हिस्सा है
यह है कि आप केवल unconnected घटक के लिए एक इकाई परीक्षण लिख सकते हैं और
स्टोर के चारों ओर पाइपिंग को संभालने के लिए रिडक्स पर भरोसा करें जैसा कि इसे करना चाहिए

यदि यह स्पष्ट नहीं है कि मेरा क्या मतलब है कि मैं एक उदाहरण पोस्ट कर सकता हूं।

कुछ विचार:

• सिर्फ एक घटक पर ध्यान केंद्रित करने का एक तरीका "उथले" प्रतिपादन का उपयोग करना है, जो वास्तव में किसी भी बच्चे को प्रस्तुत नहीं करता है
• आप अपने परीक्षणों में <Provider store={testStore}><ConnectedComponent /></Provider> भी प्रदान कर सकते हैं

FYI करें, मेरे पास यहाँ पर React / Redux परीक्षण पर कई लेखों के लिंक हैं, जो आपको मददगार मिल सकते हैं: https://github.com/markerikson/react-redux-links/blob/master/react-redux-testing। md ।

और हाँ, एक उपयोग प्रश्न के रूप में, यह वास्तव में कहीं और बेहतर पूछा गया है।

धन्यवाद @markerikson मैं वर्तमान में आपके द्वारा बताए गए उत्तरार्ध की कोशिश कर रहा हूं, लेकिन आपके लिंक की सूची को भी बुकमार्क कर देगा :)

मुझे अभी भी लगता है कि यदि आप अलगाव में एक बार घटक का परीक्षण करना चाहते हैं, तो आप ऐसा कुछ करने से बेहतर हैं

// Component.js
import React from 'react'

export const Component = ({ a, b, c }) => ( 
  // ...
)

// ...

export default connect(mapStateToProps, mapDispatchToProps)(Component)

तो आप बस अपने परीक्षण में जुड़े से पहले घटक में ला सकते हैं जैसे

// Component.spec.js
import { Component } from './Component.js'
import { mount } from 'enzyme'

it('should mount without exploding', () => {
  mount(<Component a={1} b={2} c={3} />)
})

यदि आप वास्तव में परीक्षण करना चाहते हैं, तो यह है कि आपके स्टोर में होने वाले परिवर्तन सही ढंग से प्रचारित हो रहे हैं, क्योंकि यह Provider को रेंडर करने के लिए समझ में आता है और यह अलग है, हालांकि मुझे यकीन नहीं है कि आपको परीक्षण से बहुत अधिक मूल्य मिलता है।

यहाँ चिंता का विषय यह है कि जब परीक्षण किया जा रहा घटक अन्य जुड़े घटकों को प्रस्तुत करता है, या तो प्रत्यक्ष बच्चों के रूप में या कहीं-कहीं पदानुक्रम। यदि आप mount() माध्यम से एक पूर्ण रेंडर करते हैं, तो वंशज जुड़े घटक पूरी तरह से this.context.store का उपयोग करने की कोशिश करेंगे, और इसे नहीं पाएंगे। इसलिए, मुख्य विकल्प या तो यह सुनिश्चित करते हैं कि वंशज उथले परीक्षण करके प्रस्तुत नहीं किए गए हैं, या वास्तव में स्टोर को संदर्भ में उपलब्ध करा रहे हैं।

@markerikson आह ठीक है, मैं बस फिर से पढ़ा मैंने सोचा कि ओपी बाहरी के बजाय आंतरिक घटक का परीक्षण करने की कोशिश कर रहा था। 👍

आपकी मदद के लिए धन्यवाद अब तक लोग,

इस समय मेरा जो मुख्य मुद्दा है, वह यह है कि मैं राज्य से जुड़े घटक को पास करने के लिए प्रतीत नहीं हो सकता है, जो भीतर निहित है, इस प्रकार दृश्य को सही ढंग से प्रस्तुत नहीं किया जा रहा है।

सामान्य रूप से मॉकिंग अवस्था वह चीज है जिसके बारे में मैं वास्तव में काफी संघर्ष कर रहा हूं और इस विषय पर कुछ भी निर्णायक नहीं पा रहा हूं, इसलिए यह बहुत अच्छा होगा कि अगर कोई मुझे इस बारे में कुछ विचार दे सकता है कि मैं एक नकली राज्य को कैसे पारित करूंगा? नेस्टेड कनेक्टेड या उच्चतर ऑर्डर कंपोनेंट?

तिया

@StlthyLee : "पास द स्टेट" से आपका क्या मतलब है? यदि आप अपने परीक्षण में <Provider store={store}><ComponentWithConnectedDescendants /></Provider> प्रदान करते हैं, तो उसे चीजों को संभालना चाहिए।

समस्या यह है कि ऐसा करने से, इसे सही तरीके से नहीं किया जा रहा है, घटक नेस्टेड को आवेदन राज्य से एक विशिष्ट पैरामीटर की आवश्यकता होती है जो वर्तमान में एक कारण या किसी अन्य के लिए नहीं मिल रहा है।

@StlthyLee को शायद एक उदाहरण / जिस्ट / कोडपेन / रेपो-लिंक या कुछ और करना चाहिए, इस मुद्दे को स्पॉट करने में कम समय लगेगा क्योंकि यहां शब्दावली क्लैश होने लगते हैं।

@ कोलोक उम्मीद है कि यह स्पष्ट करने में मदद करेगा

https://gist.github.com/StlthyLee/02e116d945867a77c382fa0105af1bf3

यदि नहीं, तो कृपया पूछें, क्योंकि यह ऐसी चीज है जिसकी मैं तह तक जाने के लिए उत्सुक हूं, पिछले 9-10 साल रेल की दुनिया में काम करने और उस नजरिए से टीडीडी की अच्छी समझ रखने के बाद, मैं अब इसे पाने की कोशिश कर रहा हूं। प्रतिक्रिया / Redux दुनिया में TDD के आसपास मेरा सिर।

इसलिए मुझे विश्वास है कि मैं अब इस मुद्दे की तह तक पहुँच गया हूँ, यह इतना अधिक परीक्षण का मुद्दा नहीं था, लेकिन किसी अन्य टीम के सदस्य द्वारा की गई अधिक प्रतिलिपि और पिछली त्रुटि है, मुझे लगता है कि यह हिस्सा है और इसे लिखने के लिए पार्सल होना चाहिए मेरे पसंदीदा TDD तरीकों के बजाय कोड को फिट करने के लिए परीक्षण। यहाँ दी गई सभी सूचनाओं के लिए धन्यवाद यह अत्यंत मूल्यवान है

बस एक और विकल्प पेश करने के लिए जो कुछ उपयोग मामलों के लिए काम कर सकता है, मैं हाल ही में एक नेस्टेड कनेक्टेड घटक के साथ इस समस्या में भाग गया। एक नकली स्टोर बनाने के बजाय, मैंने प्रत्येक घटक के गैर-जुड़े संस्करणों को एक स्टोर के बिना इकाई परीक्षण के लिए निर्यात किया। कुछ इस तरह:

class TopLevelImpl extends React.PureComponent {
  // Implementation goes here
}

// Export here for unit testing.  The unit test imports privates and uses TopLevel
// with Enzyme's mount().
export const privates = {
  TopLevel: TopLevelImpl,
}

export const TopLevel = connect(mapStateToProps)(TopLevelImpl)

मैंने बच्चे को नेस्टेड घटकों के लिए एक ही काम किया ताकि प्रत्येक स्वतंत्र रूप से परीक्षण करने योग्य हो।

फिर मैंने शीर्ष-स्तरीय कनेक्टेड घटक लिया और बच्चे से जुड़े घटकों को ऐप के render() फ़ंक्शन में प्रॉप्स के रूप में पारित किया। जब इकाई शीर्ष स्तर के घटक का परीक्षण कर रही है, तो जुड़े घटकों में पारित होने के बजाय, मैं सिर्फ यह सुनिश्चित करने के लिए नकली घटकों में गुजरता हूं कि वे सही जगह पर प्रदान किए गए हैं। आप गैर-जुड़े घटकों में भी पास कर सकते हैं।

कुछ इस तरह:

// Root render function
render() {
  return (
    <Provider store={store}>
      <TopLevel child1={<Child1 />} child2={<Child2 />} />
    </Provider>
  )
}

मुझे वास्तव में आपका विचार पसंद है। लेकिन मैं इसके बजाय ऐसा कुछ करता हूं

const props = {
  child1: () => (<div />),
  child2: () => (<div />)
}
<TopLevel {...props} />

मुझे लगता है कि अगर आपने पहले ही चाइल्ड 1 और चाइल्ड 2 का परीक्षण कर लिया है, तो संभवतः उन्हें आपके टॉपलेवल घटक में होने की कोई आवश्यकता नहीं है।

मैं एक फ़ंक्शन भी पास करता हूं अगर मुझे घटक को सशर्त रूप से प्रस्तुत करने की आवश्यकता होती है।

मैं हालांकि आपके अंतिम वाक्य का पालन नहीं करता। किसी अन्य घटक में बाल घटकों को पास करने के लिए परीक्षण का क्या करना है?

कुंआ। उदाहरण के लिए मेरे पास बाहरी जुड़ा हुआ घटक है जो एक या कुछ आंतरिक जुड़े घटकों का उपयोग करता है। इस मामले में अगर मैं बाहरी घटक का परीक्षण करना चाहता हूं तो मैं इस तरह से काम करता हूं

wrapper = mount(<ExternalComponent.WrappedComponent {...props} />)

हालाँकि, मुझे त्रुटि है कि मेरे आंतरिक घटकों को ठीक से चलने के लिए राज्य की आवश्यकता है।

Invariant Violation: Could not find "store" in either the context or props

फिर मैंने नकली राज्य आदि को पारित करने की कोशिश की। हालाँकि मेरे मामले में मुझे हर जुड़े घटक के लिए बहुत से इनिशियलाइज़ेशन करने पड़ते हैं, जैसे कि एसिंक्स कॉल, इनिशियलस्टेट आदि और मुझे इससे जुड़ी अन्य त्रुटियाँ थीं।

मुझे लगता है कि यह सभी आंतरिक जुड़े घटकों के लिए सभी उचित आरंभ करने के लिए एक ओवरकिल होगा, अगर मैं सिर्फ बाहरी घटक का परीक्षण करना चाहता हूं।

इसलिए मैंने सभी जुड़े हुए घटकों को बाहर निकालने का फैसला किया है और उन्हें बाहरी जुड़े घटक के रूप में पास किया है। और अब मैं उन्हें एक खाली डिव के साथ बदल सकता हूं जब मैं परीक्षण करना चाहता हूं।

अरे हाँ, यह पैटर्न के लिए सिर्फ मूल प्रेरणा थी। तो अपनी सजा को संशोधित करने के लिए, आपका मतलब था "मुझे लगता है कि यदि आपने पहले ही चाइल्ड 1 और चाइल्ड 2 का परीक्षण किया है, तो यूनिट परीक्षण करते समय उन्हें अपने टॉपलेवल घटक में पास करने की कोई आवश्यकता नहीं है।"

माना।

@StlthyLee , दुर्भाग्य से मुझे एक ही समस्या का सामना करना पड़ा जब एक घटक का परीक्षण करने की कोशिश की जाती है जिसमें जुड़े हुए घटक होते हैं।

एक समाधान जो मुझे विशेष रूप से उपयोगी लगा वह है परीक्षण के वातावरण के आधार पर नेस्टेड घटक को रिड्यूक्स स्टोर से जोड़ना।

• जब परीक्षण चलते हैं, तो एक पर्यावरण चर NODE_ENV="test" सेटअप करें। आप इस चर को पकड़ सकते हैं और घटक को डिफ़ॉल्ट गुण प्राप्त कर सकते हैं। ऐसे मामले में घटक स्टोर से जुड़ा नहीं है, और मूल घटक का परीक्षण करते समय कोई समस्या नहीं दिखाई देती है।
• अन्य मामलों में घटक को जुड़ा हुआ बनाते हैं। अनुप्रयोग में घटक को चलाते समय यह डिफ़ॉल्ट परिदृश्य है।

क) सबसे पहले, आपको एक सहायक फ़ंक्शन की आवश्यकता होगी जो यह निर्धारित करता है कि पर्यावरण test :

export default function ifTestEnv(forTestEnv, forNonTestEnv) {
  const isTestEnv = process && process.env && process.env.NODE_ENV === 'test';
  const hoc = isTestEnv ? forTestEnv : forNonTestEnv;
  return function(component) {
    return hoc(component);
  };
}

बी) अगला, पर्यावरण के आधार पर defaultProps() और connect() सशर्त रूप से लागू किया जाना चाहिए:

import React, { Component } from 'react';
import { connect } from 'react-redux';
import defaultProps from 'recompose/defaultProps';

import ifTestEnv from 'helpers/if_test_env';
import { fetch } from './actions';

class MyComponent extends Component {
   render() {
      const { propA, propB } = this.props;
      return <div>{propA} {probB}</div>
   }

   componentDidMount() {
      this.props.fetch();
   }
}

function mapStateToProps(state) {
  return {
    propA: state.valueA,
    propB: state.valueB
  };
}

export default ifTestEnv(
  defaultProps({
    propA: 'defaultA',
    propB: 'defaultB',
    fetch() {   }
  }),
  connect(mapStateToProps, { fetch })
)(MyComponent);

ग) सुनिश्चित करें कि परीक्षण चलाने पर NODE_ENV "test" :

• मोचा सीएलआई का उपयोग करते समय, परीक्षण वातावरण सेट करने के लिए एक उपसर्ग लगाएं: NODE_ENV='test' mocha app/**/*.test.jsx ।
• वेबपैक के मामले में, एक प्लगइन लागू करें:

plugins: [
    // plugins...
    new webpack.DefinePlugin({
      'process.env': {
        NODE_ENV: JSON.stringify('test')
      },
    })
]

@markerikson दो सुझावों के लिए धन्यवाद। मैंने दूसरा प्रयास किया और प्रदाता के साथ परीक्षण करने के लिए अपने घटक को लपेटा। इस मामले में mapStateToProps सही ढंग से काम करता है लेकिन मुझे mapDispatchToProps साथ अपेक्षित परिणाम नहीं मिलते हैं। यहाँ परीक्षण किया जा रहा घटक अन्य जुड़े घटकों का प्रतिपादन करता है।

मेरा MapDispatchToProps कुछ ऐसा दिखता है

/* <strong i="10">@flow</strong> */
import { bindActionCreators } from 'redux';

import type { Dispatch } from './types';
import * as actions from './actions';

export default (dispatch: Dispatch, ownProps: Object): Object => ({
  actions: bindActionCreators(actions, dispatch),
});

यहां लौटाए गए कार्यों का मूल्य undefined ।

store.js

import { applyMiddleware, compose, createStore } from 'redux';
import { autoRehydrate } from 'redux-persist';
import thunk from 'redux-thunk';

import rootReducer from './reducers';
import { REHYDRATE } from 'redux-persist/constants';

const store = compose(autoRehydrate(), applyMiddleware(thunk, createActionBuffer(REHYDRATE)))(createStore)(rootReducer);

export default store;

मुझे लगता है कि यह काफी पुराना धागा है, लेकिन मैंने इसे एक उपद्रव के मुद्दे के रूप में पाया और सोचा कि यह समाधान किसी ऐसे व्यक्ति की मदद कर सकता है जो इस धागे पर (मेरी तरह) ठोकर खाता है।

जैसा कि मैं वास्तव में Redux से संबंधित किसी भी चीज़ का परीक्षण नहीं कर रहा था, एक सरल समाधान जो मैंने पाया कि कनेक्ट किए गए फ़ंक्शन को केवल अनछुए घटक को वापस करने के लिए मॉक किया गया था।

जैसे आपके आवेदन में आपके पास एक घटक हो सकता है:

export class ExampleApp extends Component {
  render() {
  }
}

export default connect(
  null,
  { someAction }
)(ExampleApp);

फिर अपनी परीक्षण फ़ाइल की शुरुआत में आप अपने घटक के साथ Redux बातचीत को रोकने के लिए एक नकली कनेक्ट फ़ंक्शन रख सकते हैं:

jest.mock("react-redux", () => {
  return {
    connect: (mapStateToProps, mapDispatchToProps) => (
      ReactComponent
    ) => ReactComponent
  };
});

इस मॉकिंग को प्रत्येक परीक्षण फ़ाइल में रखा जाना चाहिए जो एक जुड़े हुए बच्चे की नकल करता है।

@scottbanyard आप बच्चे के घटक को