🛀🏻 🔇 🧙🏽 Redux-saga के परीक्षण की मेटामॉर्फोसिस 👨🏾‍🔧 🎷 👍

redux-saga फ्रेमवर्क साइड इफेक्ट्स के साथ काम करने के लिए दिलचस्प पैटर्न का एक गुच्छा प्रदान करता है, लेकिन, सच्चे खूनी उद्यम डेवलपर्स की तरह, हमें परीक्षणों के साथ अपने पूरे कोड को कवर करने की आवश्यकता है। आइए जानें कि हम अपने सागों का परीक्षण कैसे करेंगे।

उदाहरण के रूप में सबसे सरल क्लिकर को लें। डेटा प्रवाह और आवेदन का अर्थ इस प्रकार होगा:

उपयोगकर्ता एक बटन दबाता है।
सर्वर को एक अनुरोध भेजा जाता है, जिसमें बताया जाता है कि उपयोगकर्ता ने एक बटन दबाया है।
सर्वर किए गए क्लिकों की संख्या लौटाता है।
राज्य द्वारा किए गए क्लिकों की संख्या को रिकॉर्ड करता है।
UI अपडेट किया गया है, और उपयोगकर्ता देखता है कि क्लिक की संख्या में वृद्धि हुई है।
...
लाभ।

हमारे काम में, हम टाइपस्क्रिप्ट का उपयोग करते हैं, इसलिए सभी उदाहरण इस भाषा में होंगे।

जैसा कि आप शायद पहले ही अनुमान लगा चुके हैं, हम यह सब redux-saga साथ लागू करेंगे। यहाँ पूरी सागा फ़ाइल के लिए कोड है:

 export function* processClick() { const result = yield call(ServerApi.SendClick) yield put(Actions.clickSuccess(result)) } export function* watchClick() { yield takeEvery(ActionTypes.CLICK, processClick) }

इस सरल उदाहरण में, हम गाथा processClick घोषणा करते हैं, जो सीधे क्रिया को संसाधित करता है और गाथा watchClick , जो प्रसंस्करण action' लिए एक लूप बनाता है।

जनरेटर

तो हमारे पास सबसे सरल गाथा है। यह सर्वर ( call) लिए एक अनुरोध भेजता है, परिणाम प्राप्त करता है और इसे reducer ( put) । हमें किसी तरह परीक्षण करने की आवश्यकता है कि क्या गाथा सर्वर से वास्तव में प्राप्त कर रही है। चलिए शुरू करते हैं।

परीक्षण के लिए, हमें सर्वर कॉल को लॉक करने की जरूरत है और किसी तरह जांच लें कि क्या सर्वर से आया रीड्यूसर में चला गया।

चूंकि सागा जनरेटर फ़ंक्शन हैं, next() विधि, जो जनरेटर प्रोटोटाइप में है, परीक्षण करने का सबसे स्पष्ट तरीका होगा। इस पद्धति का उपयोग करते समय, हमारे पास जनरेटर से अगला मूल्य प्राप्त करने और जनरेटर को मूल्य हस्तांतरित करने का अवसर होता है। इस प्रकार, हम बॉक्स से गीले कॉल प्राप्त करने का अवसर प्राप्त करते हैं। लेकिन क्या सब कुछ इतना रसपूर्ण है? यहाँ एक परीक्षण है जो मैंने नंगे जनरेटर पर लिखा है:

 it('should increment click counter (behaviour test)', () => { const saga = processClick() expect(saga.next().value).toEqual(call(ServerApi.SendClick)) expect(saga.next(10).value).toEqual(put(Actions.clickSuccess(10))) })

परीक्षण संक्षिप्त था, लेकिन यह क्या परीक्षण करता है? वास्तव में, यह केवल गाथा विधि के कोड को दोहराता है, अर्थात, गाथा में किसी भी परिवर्तन से परीक्षण को बदलना होगा।

ऐसा परीक्षण विकास में मदद नहीं करता है।

Redux-गाथा परीक्षण योजना

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

प्रस्तावित सूची से हमने redux-saga-test-plan पुस्तकालय को लिया। यहाँ मैंने इसके साथ लिखे गए परीक्षण के पहले संस्करण का कोड दिया है:

 it('should increment click counter (behaviour test with test-plan)', () => { return expectSaga(processClick) .provide([ call(ServerApi.SendClick), 2] ]) .dispatch(Actions.click()) .call(ServerApi.SendClick) .put(Actions.clickSuccess(2)) .run() })

expectSaga redux-saga-test-plan में टेस्ट कंस्ट्रक्टर expectSaga फ़ंक्शन, जो परीक्षण का वर्णन करने वाले इंटरफ़ेस को लौटाता है। परीक्षण गाथा (पहली सूची से processClick ) समारोह में ही पास हो जाती है।

provide विधि का उपयोग करके, आप सर्वर कॉल या अन्य निर्भरता को रोक सकते हैं। StaticProvider' की एक सरणी StaticProvider' , जो बताती है कि किस विधि को वापस लौटना चाहिए।

Act ब्लॉक में, हमारे पास एक एकल विधि है - dispatch । इसके लिए एक कार्रवाई की जाती है, जिसके लिए गाथा जवाब देगी।

assert ब्लॉक में call put तरीके होते हैं, जो यह जांचते हैं कि गाथा के काम के दौरान क्या संगत प्रभाव थे।

यह सब run() विधि के साथ समाप्त होता है। यह विधि सीधे परीक्षण चलाती है।

इस दृष्टिकोण के लाभ:

यह जांचता है कि क्या विधि को कॉल किया गया था, और कॉल का अनुक्रम नहीं;
मोकी स्पष्ट रूप से वर्णन करता है कि कौन सा फ़ंक्शन गीला हो जाता है और कौन से रिटर्न।

हालांकि, वहाँ काम करना है:

अधिक कोड है;
परीक्षा को पढ़ना मुश्किल है;
यह व्यवहार के लिए एक परीक्षण है, जिसका अर्थ है कि यह अभी भी गाथा के कार्यान्वयन से जुड़ा हुआ है।

अंतिम दो स्ट्रोक

हालत परीक्षण

सबसे पहले, हम पिछले एक को ठीक करते हैं: हम एक व्यवहार परीक्षण से एक राज्य परीक्षण करते हैं। तथ्य यह है कि test-plan हमें प्रारंभिक state निर्धारित करने और reducer पास करने की अनुमति देती है, जो कि गाथा द्वारा उत्पन्न प्रभावों को जवाब देना चाहिए, इससे हमें मदद मिलेगी। यह इस तरह दिखता है:

 it('should increment click counter (state test with test-plan)', () => { const initialState = { clickCount: 11, return expectSaga(processClick) .provide([ call(ServerApi.SendClick), 14] ]) .withReducer(rootReducer, initialState) .dispatch(Actions.click()) .run() .then(result => expect(result.storeState.clickCount).toBe(14)) })

इस परीक्षण में, हम अब यह सत्यापित नहीं करते हैं कि कोई प्रभाव ट्रिगर किया गया था। हम निष्पादन के बाद अंतिम स्थिति की जांच करते हैं, और यह ठीक है।

हम गाथा के कार्यान्वयन से छुटकारा पाने में कामयाब रहे, अब परीक्षण को और अधिक समझने की कोशिश करते हैं। यह आसान है अगर आप then() async/await साथ प्रतिस्थापित करते हैं:

 it('should increment click counter (state test with test-plan async-way)', async () => { const initialState = { clickCount: 11, } const saga = expectSaga(processClick) .provide([ call(ServerApi.SendClick), 14] ]) .withReducer(rootReducer, initialState) const result = await saga.dispatch(Actions.click()).run() expect(result.storeState.clickCount).toBe(14) })

एकीकरण परीक्षण

लेकिन क्या होगा अगर हमें एक रिवर्स क्लिक ऑपरेशन मिला है (चलो इसे अशुद्ध कहते हैं), और अब हमारी sag फाइल इस तरह दिखती है:

 export function* processClick() { const result = yield call(ServerApi.SendClick) yield put(Actions.clickSuccess(result)) } export function* processUnclick() { const result = yield call(ServerApi.SendUnclick) yield put(Actions.clickSuccess(result)) } function* watchClick() { yield takeEvery(ActionTypes.CLICK, processClick) } function* watchUnclick() { yield takeEvery(ActionTypes.UNCLICK, processUnclick) } export default function* mainSaga() { yield all([watchClick(), watchUnclick()]) }

मान लें कि हमें यह परीक्षण करने की आवश्यकता है कि जब क्लिक और अशुद्ध क्रियाओं को राज्य में कहा जाता है, तो सर्वर की अंतिम यात्रा का परिणाम राज्य को लिखा जाता है। ऐसा परीक्षण redux-saga-test-plan साथ भी आसानी से किया जा सकता है:

 it('should change click counter (integration test)', async () => { const initialState = { clickCount: 11, } const saga = expectSaga(mainSaga) .provide([ call(ServerApi.SendClick), 14], call(ServerApi.SendUnclick), 18] ]) .withReducer(rootReducer, initialState) const result = await saga .dispatch(Actions.click()) .dispatch(Actions.unclick()) .run() expect(result.storeState.clickCount).toBe(18) })

कृपया ध्यान दें कि अब हम mainSaga का परीक्षण कर रहे हैं, न कि व्यक्तिगत mainSaga हैंडलर का।

हालाँकि, यदि हम इस परीक्षण को चलाते हैं, तो हमें Vorning मिल जाएगा:

यह takeEvery प्रभाव के कारण है - यह एक संदेश प्रसंस्करण लूप है जो हमारे आवेदन के खुले रहने पर काम करेगा। तदनुसार, जिस परीक्षा में takeEvery कहा जाता है, takeEvery बाहर की मदद के बिना काम को पूरा करने में सक्षम नहीं takeEvery , और redux-saga-test-plan की शुरुआत के बाद 250 एमएस के बाद इन प्रभावों को जबरन समाप्त कर देती है। इस टाइमआउट को अपेक्षित रूप से कॉल करके बदला जा सकता है।

यदि आप ऐसी वोरिंग प्राप्त नहीं करना चाहते हैं, तो प्रत्येक परीक्षण के लिए एक जटिल प्रभाव के साथ, बस run() विधि के बजाय साइलेंट रून run() विधि का उपयोग करें।

नुकसान

जहां नुकसान के बिना ... इस लेखन के समय, रेडक्स-सागा का नवीनतम संस्करण: 1.0.2। इसी समय, redux-saga-test-plan केवल जेएस पर इसके साथ काम करने में सक्षम है।

यदि आप टाइपस्क्रिप्ट चाहते हैं, तो आपको बीटा चैनल से संस्करण को स्थापित करना होगा:
npm install redux-saga-test-plan@beta
और निर्माण से परीक्षण बंद कर दें। ऐसा करने के लिए, tsconfig.json फ़ाइल में, आपको "बहिष्कृत" फ़ील्ड में पथ को निर्दिष्ट करने की आवश्यकता है "./src/**/*.spec.ts"।

इसके बावजूद, हम redux-saga-test-plan लिए सर्वश्रेष्ठ पुस्तकालय पर विचार करते हैं। यदि आपके पास अपने प्रोजेक्ट में redux-saga है, तो शायद यह आपके लिए एक अच्छा विकल्प होगा।

GitHub पर उदाहरण का स्रोत कोड।