Redux: यूनिट परीक्षण स्मार्ट घटकों

को निर्मित 20 अग॰ 2015 · 19टिप्पणियाँ · स्रोत: reduxjs/redux

मैं प्रलेखन के यूनिट परीक्षण खंड के माध्यम से पढ़ रहा था और जबकि इसका एक उदाहरण है कि कैसे एक गूंगा घटक का परीक्षण किया जाए, इकाई को "स्मार्ट घटक" (जो कनेक्ट का उपयोग करते हैं) का परीक्षण करने में सक्षम नहीं है। यह पता चला है कि एक स्मार्ट घटक का परीक्षण करने वाला इकाई आवरण घटक के कारण थोड़ा अधिक जटिल है जो कनेक्ट () बनाता है। समस्या का एक हिस्सा यह है कि कनेक्ट () के माध्यम से एक घटक को लपेटने के लिए आवश्यक है कि एक 'स्टोर' प्रोप (या संदर्भ) हो।

मैंने ऐसा करने की कोशिश में एक दरार ले ली और मुझे उम्मीद थी कि इसे पूरा करने का एक बेहतर तरीका है या नहीं। और अगर मैंने जो किया है, वह उचित लग रहा है, तो मुझे लगा कि मैं इस परीक्षण इकाई में कुछ जानकारी जोड़ने के लिए एक पीआर को आगे बढ़ाऊंगा।

शुरू करने के लिए, मैंने डॉक्स के यूनिट टेस्ट सेक्शन में मौजूदा उदाहरण घटक को लिया, और इसे कनेक्ट से कनेक्ट किया () राज्य से डेटा पास करने के लिए और प्रेषण-बद्ध एक्शन क्रिएटर्स:

Header.js (स्मार्ट घटक)

import React, { PropTypes, Component } from 'react';
import TodoTextInput from './TodoTextInput';
import TodoActions from '../actions/TodoActions';
import connect from 'redux-react';

class Header extends Component {
  handleSave(text) {
    if (text.length !== 0) {
      this.props.addTodo(text);
    }
  }

  render() {
    return (
      <header className='header'>
          <h1>{this.props.numberOfTodos + " Todos"}</h1>
          <TodoTextInput newTodo={true}
                         onSave={this.handleSave.bind(this)}
                         placeholder='What needs to be done?' />
      </header>
    );
  }
}

export default connect(
  (state) =>  {numberOfTodos: state.todos.length},
  TodoActions
)(Header);

यूनिट टेस्ट फाइल में यह उदाहरण के समान दिखता है।

Header.test.js

import expect from 'expect';
import jsdomReact from '../jsdomReact';
import React from 'react/addons';
import Header from '../../components/Header';
import TodoTextInput from '../../components/TodoTextInput';
const { TestUtils } = React.addons;

/**
 * Mock out the top level Redux store with all the required 
 * methods and have it return the provided state by default.
 * <strong i="13">@param</strong> {Object} state State to populate in store
 * <strong i="14">@return</strong> {Object} Mock store
 */
function createMockStore(state) {
  return {
    subscribe: () => {},
    dispatch: () => {},
    getState: () => {
      return {...state};
    }
  };
}

/**
 * Render the Header component with a mock store populated
 * with the provided state
 * <strong i="15">@param</strong> {Object} storeState State to populate in mock store
 * <strong i="16">@return</strong> {Object} Rendered output from component
 */
function setup(storeState) {
  let renderer = TestUtils.createRenderer();
  renderer.render(<Header store={createMockStore(storeState)} />);
  var output = renderer.getRenderedOutput();
  return output.refs.wrappedInstance();
}

describe('components', () => {
  jsdomReact();

  describe('Header', () => {
    it('should call call addTodo if length of text is greater than 0', () => {
      const output = setup({
        todos: [1, 2, 3]
      });
      var addTodoSpy = expect.spyOn(output.props, 'addTodo');

      let input = output.props.children[1];
      input.props.onSave('');
      expect(addTodoSpy.calls.length).toBe(0);
      input.props.onSave('Use Redux');
      expect(addTodoSpy.calls.length).toBe(1);
    });
  });
});

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

इस दृष्टिकोण से मैं जो लाभ देख सकता हूं, वह यह है कि यह मुझे अपने घटक के भीतर कार्यों का परीक्षण करने की अनुमति देता है, लेकिन उन तरीकों की कार्यक्षमता का परीक्षण करने में सक्षम हो सकता है जो मैं कनेक्ट कर रहा हूं ()। मैं यहाँ आसानी से एक और दावा लिख सकता हूँ जो expect(output.props.numberOfTodos).toBe(3) जैसा कुछ करता है जो यह सत्यापित करता है कि मेरा mapStateToProps फ़ंक्शन वही कर रहा है जिसकी मुझे अपेक्षा है।

इसका मुख्य नकारात्मक पक्ष यह है कि मुझे Redux स्टोर का मज़ाक उड़ाना पड़ रहा है, जो कि जटिल नहीं है, लेकिन ऐसा लगता है कि यह आंतरिक Redux तर्क का हिस्सा है और इसमें बदलाव हो सकता है। जाहिर है मेरी इकाई परीक्षणों के लिए मैंने इन विधियों को एक सामान्य इकाई परीक्षण उपयोगिता फ़ाइल में स्थानांतरित कर दिया है ताकि यदि स्टोर के तरीकों में बदलाव आए, तो मुझे केवल एक जगह अपना कोड संशोधित करना होगा।

विचार? क्या किसी और ने स्मार्ट उपकरणों के परीक्षण के लिए यूनिट के साथ प्रयोग किया है और चीजों को करने का एक बेहतर तरीका पाया है?

discussion question

स्रोत

ernieturner

👍1

सबसे उपयोगी टिप्पणी

@ernieturner मुझे लगता है कि @ghengeveld का मतलब यह है कि यदि आप हर जगह ES6 मॉड्यूल का उपयोग करते हैं, तो सजाया गया हैडर घटक अभी भी डिफ़ॉल्ट के रूप में निर्यात किया जा सकता है, और एक सादा रिएक्ट घटक एक अतिरिक्त नामित निर्यात हो सकता है। उदाहरण के लिए -

//header.js
export class HeaderDumbComponent {
  render() {
    return <header><div>...</div></header>;
  }
}

export default connect(
  (state) =>  {numberOfTodos: state.todos.length},
  TodoActions
)(HeaderDumbComponent);

इस दोहरे निर्यात के साथ, आपका मुख्य ऐप import Header from './header.js' साथ पहले की तरह स्मार्ट घटक का उपभोग कर सकता है, जबकि आपके परीक्षण Redux को बायपास कर सकते हैं और कोर घटक के व्यवहार का सीधे import {HeaderDumbComponent} from '../components/header.js' साथ परीक्षण कर सकते हैं।

eugene1g 21 अग॰ 2015

👍18

सभी 19 टिप्पणियाँ

इसका विकल्प हैडर (अघोषित) हैडर वर्ग को भी निर्यात करना है, इसलिए इसे अलग से आयात और परीक्षण किया जा सकता है।

इसके अलावा, आपको हर फ़ाइल में jsdomReact कॉल की आवश्यकता नहीं है, कम से कम यदि आप मोचा का उपयोग कर रहे हैं। यहाँ मेरा setup.js है:

import jsdom from 'jsdom';
import ExecutionEnvironment from 'react/lib/ExecutionEnvironment';

if (!global.document || !global.window) {
  global.document = jsdom.jsdom('<!doctype html><html><body></body></html>');
  global.window = document.defaultView;
  global.navigator = window.navigator;

  ExecutionEnvironment.canUseDOM = true;

  window.addEventListener('load', () => {
    console.log('JSDom setup completed: document, window and navigator are now on global scope.');
  });
}

यह --require कमांड लाइन विकल्प के माध्यम से लोड किया गया है: mocha -r babelhook -r test/setup --recursive (babelhook require('babel-core/register') लिए एक कॉल है)।

ghengeveld 20 अग॰ 2015

हां, मैं हेडर वर्ग और सजाए गए दोनों को निर्यात कर सकता हूं, लेकिन मैं अपनी इकाई परीक्षणों के लिए स्रोत कोड बदलने से बचने की उम्मीद कर रहा था। ऐसा करने से मुझे उन सभी स्थानों को बदलना पड़ेगा जिनमें एक सजाया हुआ घटक शामिल है (जैसे import {DecoratedHeader} from './components/Header' बजाय सिर्फ import Header from / घटकों / Header`)।

Jsdom सेटअप के लिए, मैं विशुद्ध रूप से उदाहरणों को उपयोग के मामले को दिखाने के तरीके के रूप में डॉक्स से कॉपी कर रहा था, मैं इसे अपने मुख्य सेटअप के रूप में उपयोग नहीं कर रहा हूँ, सिर्फ एक उदाहरण के रूप में।

ernieturner 20 अग॰ 2015

मैंने अभी देखा कि मेरे कोड का नमूना अधूरा था। सीधे तौर पर एक स्मार्ट घटक का परीक्षण करने के लिए, आपके पास कुछ उपयोगी विधि होनी चाहिए, जिससे आपको केवल refs.wrappedInstance मिलेंगे, केवल इसके परिणामस्वरूप रेंडर करने से आपको कनेक्ट-सजा हुआ घटक (ऊपर सेटअप फ़ंक्शन में अद्यतन) मिलेगा । यह फिर से थोड़े यूनिट परीक्षणों को Redux के आंतरिक (इस मामले में, विशेष रूप से प्रतिक्रिया- redux के आंतरिक) पर निर्भर करता है। तो यह काम करता है, लेकिन थोड़ा नाजुक लगता है।

ernieturner 21 अग॰ 2015

@ernieturner हम इसके लिए getWrappedInstance() public API भी प्रदान करते हैं ताकि आप इस पर भरोसा कर सकें यदि आप refs सीधे एक्सेस करने के बारे में चिंतित हैं। और इस पारदर्शी बनाने के लिए प्रतिक्रिया-परीक्षण-वृक्ष जैसी उपयोगिताएँ भी हैं।

gaearon 21 अग॰ 2015

//header.js
export class HeaderDumbComponent {
  render() {
    return <header><div>...</div></header>;
  }
}

export default connect(
  (state) =>  {numberOfTodos: state.todos.length},
  TodoActions
)(HeaderDumbComponent);

eugene1g 21 अग॰ 2015

👍18

@ eugene1g @ghengeveld यह वास्तव में समस्या का एक बहुत अच्छा समाधान है। "लेखन परीक्षण" के लिए एक पीआर भेजने के लिए बेझिझक डॉक्टर इसे समझाते हुए!

gaearon 21 अग॰ 2015

@ eugene1g मेरा वास्तव में यही मतलब है।
@gaearon मैं ऐसा करूँगा।

ghengeveld 21 अग॰ 2015

@ghengeveld गलतफहमी के लिए माफी। मैं अभी भी कॉमनजस शैली के आयात का उपयोग कर रहा हूं, इसलिए मैं अभी भी ईएस 6 मॉड्यूल पर बहुत अधिक कठोर हूं। यह डॉक्स में उजागर करने के लिए एक अच्छा समाधान की तरह प्रतीत होता है। मुझे लगता है कि आप मैपस्टैटटॉप्रोप्स / मैपडाइस्पेक्टटाउप्रॉप्स के तरीकों को भी उजागर कर सकते थे, साथ ही उन लोगों को स्टोर से बाहर मॉकिंग करने के लिए परीक्षण किए बिना अनुमति देने के लिए, जैसे।

export class HeaderDumpComponent ...

export function mapStateToProps(state) ... 
export function mapDispatchToProps(dispatch) ...

export default connect(mapStateToProps, mapDispatchToProps)(HeaderDumpComponent);

यह बहुत संभव है कि नक्शे के अधिकांश तरीके यूनिट परीक्षण की आवश्यकता नहीं करने के लिए पर्याप्त सरल होंगे, लेकिन मेरे पास उनमें से कुछ सत्यापित करने लायक होंगे क्योंकि वे मेरे घटकों की कार्यक्षमता का एक महत्वपूर्ण हिस्सा हैं।

सभी के सुझावों के लिए धन्यवाद, अगर आपको दस्तावेज़ीकरण में कोई मदद चाहिए, तो मुझे बताएं।

ernieturner 21 अग॰ 2015

हम अनुशंसित दृष्टिकोण की कोशिश कर रहे हैं जैसा कि अभी ऊपर उल्लिखित है, लेकिन हम इसके साथ पूरी तरह से सहज महसूस नहीं करते हैं। यह एकीकरण परीक्षणों के बाहर connect अप्रमाणित किए गए मापदंडों को छोड़ देता है। मैं समझता हूं कि एक नकली स्टोर संभावित रूप से भंगुर हो सकता है, लेकिन मुझे ऐसा लगता है कि जहां Redux-mock-store जैसी कोई चीज कूद सकती है, अगर वह कंपोनेंट परीक्षण का समर्थन कर सकती है। आप उस दिशा के बारे में कैसा महसूस करते हैं?

carpeliam 3 नव॰ 2015

@carpeliam

क्यों न केवल एक नियमित स्टोर का उपयोग करें और इसे एक विशेष प्रारंभिक अवस्था के साथ हाइड्रेट करें?
आपको केवल स्टोर को मॉक करने की आवश्यकता है यदि आप परीक्षण करना चाहते हैं कि कौन से कार्य भेजे जा रहे हैं।

gaearon 3 नव॰ 2015

@carpeliam

कृपया इस रेपो में counter और todomvc लिए यूनिट परीक्षण देखें।

gaearon 3 नव॰ 2015

हमारे पास एक समस्या थी जहां हम एक अन्य घटक के अंदर एक स्मार्ट घटक प्रदान कर रहे थे और उथले रेंडरर (घटक इस्तेमाल किए गए घटक) या तरीकों का उपयोग नहीं कर सकते थे। हमने जो किया वह स्टब (सिनॉन का उपयोग करके) एक साधारण रिएक्ट घटक को वापस करने वाले फ़ंक्शन को वापस करने के लिए कनेक्ट फ़ंक्शन को किया।

यह भंगुर है और हम उम्मीद करते हैं कि उथले रेंडरर में चले जाने के बाद एक बार हम रिएक्ट 0.14 पर माइग्रेट कर सकते हैं, लेकिन इस पद्धति ने हमें समय पर परीक्षण के लिए अनब्लॉक कर दिया।

songawee 24 नव॰ 2015

मुझे इससे थोड़ी परेशानी हो रही है। मैं रिएक्ट और रेडक्स दोनों के लिए एक जैसा नहीं हूं, इसलिए यह संभव है कि मुझे वापस पकड़ा जाए। आप इसे कैसे प्राप्त कर पाए? @songawee

adrianObel 2 दिस॰ 2015

प्रस्तावित डबल एक्सपोर्ट विधि चुनिंदा (mapStoreToState) फ़ंक्शन को छोड़ देता है। स्वतंत्र रूप से इसका परीक्षण करने के लिए इसे निर्यात करने की आवश्यकता है, फिर भी परीक्षण के नाम पर एक और बदलाव।

मैं कनेक्ट के लिपटे घटक के साथ काम करने के लिए उथला-पतला होने का रास्ता खोजने में दिलचस्पी रखता हूं। मेरी वर्तमान समस्या यह है कि उथले रेंडरर का उपयोग करते समय यह केवल कनेक्ट घटक को वापस पारित करता है, जिसकी उम्मीद की जानी है।

wwalser 19 फ़र॰ 2016

प्रस्तावित डबल एक्सपोर्ट विधि चुनिंदा (mapStoreToState) फ़ंक्शन को छोड़ देता है। स्वतंत्र रूप से इसका परीक्षण करने के लिए इसे निर्यात करने की आवश्यकता है, फिर भी परीक्षण के नाम पर एक और बदलाव।

सख्ती से नहीं "परीक्षण के नाम पर"। वास्तव में हम आपको चयनकर्ताओं के कार्यों को परिभाषित करने के लिए प्रोत्साहित करते हैं (जो कि mapStateToProps अंततः है) अपने रीड्यूसर के साथ, और उन्हें एक साथ परीक्षण करते हैं। यह तर्क UI से स्वतंत्र है और इसके साथ बंडल नहीं किया जाना है। कुछ चयनकर्ताओं के लिए shopping-cart उदाहरण देखें।

gaearon 19 फ़र॰ 2016

👍3

तो @gaearon , क्या आप इस _selector_ फ़ंक्शन का उपयोग करके राज्य से सभी डेटा प्राप्त करने का सुझाव दे रहे हैं? क्या यह बहुत सारे अनावश्यक उपरि का परिचय नहीं है, क्योंकि ज्यादातर मामलों में लोग सिर्फ राज्य से संपत्तियों का एक गुच्छा पढ़ेंगे और उन्हें घटकों पर सहारा देंगे?

romulobr 15 जून 2016

हां, Redux के लिए सामान्य रूप से सुझाया गया पैटर्न state.some.nested.field सीधे एक्सेस करने के बजाय चयनकर्ता फ़ंक्शंस का बहुत अधिक उपयोग करना है। वे बहुत सरल "सादे" कार्य कर सकते हैं, लेकिन आमतौर पर रेसेलेट लाइब्रेरी का उपयोग करके एक साथ रखा जाता है, जो संस्मरण क्षमताओं को प्रदान करता है।

वह कोई अतिरिक्त उपरि क्यों बनाएगा?

markerikson 15 जून 2016

मैं यहाँ बताए अनुसार दोहरा निर्यात कर रहा हूँ लेकिन connect स्रोत को पढ़कर मुझे लगा कि "कंटेनर" WrappedComponent स्थिर संपत्ति में "गूंगा" घटक का संदर्भ रखता है:

कोड में: https://github.com/reactjs/react-redux/blob/master/src/compenders/connect.js#L344
डॉक्स में: https://github.com/reactjs/react-redux/blob/master/docs/api.md#static -properties

इसलिए इसके बजाय:

// header.js
export const HeaderDumbComponent = (props) => <header><div>...</div></header>
export default connect(mapStateToProps)(HeaderDumbComponent)


// header.spec.js
import { HeaderDumbComponent } from './header'

it('renders', () => {
  expect(<HeaderDumbComponent />).to.not.be.null
})

आप WrappedComponent का उपयोग करके दोहरे निर्यात से बच सकते हैं जहां आपको "गूंगा" संस्करण की आवश्यकता है:

// header.js
const HeaderDumbComponent = (props) => <header><div>...</div></header>
export default connect(mapStateToProps)(HeaderDumbComponent)


// header.spec.js
import Header from './header'

it('renders', () => {
  expect(<Header.WrappedComponent />).to.not.be.null
})

@gaearon - WrappedComponent डॉक्स में दी गई एक बहुत ही स्थिर संपत्ति है। क्या आप किसी भी कारण से इस तरह से इसका इस्तेमाल करने के खिलाफ सलाह देंगे?

jeffcarbs 21 अक्तू॰ 2016

👍14

मैं जो करता है, वह अलिखित घटक को निर्यात करता है, और mapStateToProps और mapDispatchToProps को भी निर्यात करता है ताकि मैं उन कार्यों का परीक्षण कर सकूं। यहाँ एक उदाहरण है:

import {ManageCoursePage, mapStateToProps, mapDispatchToProps} from './ManageCoursePage';

describe("mapStateToProps", () => {
    function setup(courses, authors, id) {
        const state = {
            authors: authors
        };

        const ownProps = {
            params: {
                id: id
            }
        };

        return mapStateToProps(state, ownProps);
    }

    it('sets the course when a course id is set', () => {
        const courses = [ { id: "1", foo: "bar" }, { id: "2", foo: "notbar" } ];
        const authors = [];
        const id = "1";

        const props = setup(courses, authors, id);

        expect(props.course).toBe(courses[0]);
    });

    it('sets the course when a course id is not set', () => {
        const courses = [ { id: "1", foo: "bar" }, { id: "2", foo: "notbar" } ];
        const authors = [];

        const props = setup(courses, authors, null);

        expect(props.course).toEqual({});
    });

    it('sets the course when a course id is set that is not present in the courses list', () => {
        const courses = [ { id: "1", foo: "bar" }, { id: "2", foo: "notbar" } ];
        const authors = [];
        const id = "42";

        const props = setup(courses, authors, null);

        expect(props.course).toEqual({});
    });

    it('sets the authors formatted for a drop down list', () => {
        const courses = [];
        const authors = [ { id: "1", name: "John" }, { id: "2", name: "Jill" }];

        const props = setup(courses, authors, null);

        expect(props.authors).toEqual([
            { value: "1", text: "John" },
            { value: "2", text: "Jill" }
        ])
    });
});

claassen 20 नव॰ 2016

👍3

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Redux: यूनिट परीक्षण स्मार्ट घटकों

Header.js (स्मार्ट घटक)

Header.test.js

सबसे उपयोगी टिप्पणी

सभी 19 टिप्पणियाँ

संबंधित मुद्दों