Knex: Knex का उपयोग करने वाले तरीकों के लिए इकाई परीक्षण कैसे लिखें।

मैंने स्पष्ट रूप से कल रात एक खराब काम किया था, क्योंकि मैंने अभी "knex.js के साथ परमाणु इकाई परीक्षण कैसे लिखना है" के साथ फिर से कोशिश की, और मुझे कुछ दिलचस्प परिणाम मिल रहे हैं। अब उनके माध्यम से पढ़ने के लिए जा रहे हैं। अगर मैं कुछ सीखता हूं तो फिर से पोस्ट करूंगा।

नहीं - कुछ नहीं मिला। स्रोतों के कालानुक्रमिक क्रम में सारांश:

2016-04-21 https://medium.com/@jomaora/knex -bookshelf-mocks- और यूनिट-परीक्षण-cca627565d3

रणनीति: मॉक-नॉक्स का उपयोग करें। मैं DB का मजाक नहीं उड़ाना चाहता हूं - मैं सही व्यवहार सुनिश्चित करने के लिए एक वास्तविक MySQL DB के खिलाफ अपने तरीकों का परीक्षण करना चाहता हूं - लेकिन मैंने mock-knex वैसे भी देख लिया ... यह सिर्फ सबसे खराब डिजाइन की गई लाइब्रेरी हो सकती है मैंने कभी सामना किया। :(

2016-04-28 http://mherman.org/blog/2016/04/28/test-driven-development-with/nlog/

रणनीति: प्रत्येक परीक्षण के बाद रोलबैक / रीमगेट / डीबी को फिर से शुरू करना। ऐसा लगता है कि प्रत्येक परीक्षण के लिए ओवरहेड का एक बड़ा सौदा है, और बहुत धीमी गति से चलेगा। प्रत्येक परीक्षण के DB नाम के लिए UUID बनाकर Concurrency प्राप्त की जा सकती है, लेकिन यह लेनदेन के लालित्य की तुलना में एक भयानक समाधान की तरह लगता है ...

2015-09-23 http://stackoverflow.com/a/32749601/210867

रणनीति: प्रत्येक परीक्षण के लिए DB को परीक्षण, बनाने / नष्ट करने के लिए साइक्लाइट का उपयोग करें। मैंने ऊपर दिए गए इस दृष्टिकोण को नापसंद करते हुए दोनों कारणों को कवर किया है।

इसलिए ... सुझावों के लिए अभी भी मछली पकड़ना, और Knex लेनदेन वास्तव में कैसे काम करते हैं, इस पर अतिरिक्त मार्गदर्शन, साथ ही साथ उन्हें मेरे उपयोग के मामले में ठीक से कैसे लागू किया जाए।

@odigity अच्छी तरह से खराब परीक्षण प्रथाओं को अभिव्यक्त किया

हम अपने "यूनिट" परीक्षण इस तरह कर रहे हैं:

1. सिस्टम शुरू करें, डीबी को इनिशियलाइज़ करें और माइग्रेशन चलाएं

2. प्रत्येक परीक्षण से पहले हम सभी तालिकाओं और अनुक्रमों (knex-db-manager पैकेज के साथ) को काटते हैं

3. परीक्षण मामले के लिए आवश्यक डेटा सम्मिलित करें (हम knex आधारित आपत्ति.js ORM का उपयोग करते हैं, जो हमें एकल कमांड के साथ नेस्टेड ऑब्जेक्ट पदानुक्रम सम्मिलित करने की अनुमति देता है, यह जानता है कि आवेषण का अनुकूलन कैसे करें ताकि इसे प्रत्येक पंक्ति के लिए अलग-अलग सम्मिलित न करना पड़े। तालिका में, लेकिन आमतौर पर प्रति तालिका केवल एक सम्मिलित होती है)

4. रन 1 टेस्ट और गोटो चरण 2

E2e परीक्षणों के साथ हमने saveState / RestoreState (pg_restore / pg_dump के साथ) विधियों को लागू किया है, जो हमें टेस्ट रन के दौरान कुछ निश्चित अवस्था में वापस आने की अनुमति देता है, इसलिए हमें हर बार जब 20 बार दौड़ने के बाद कोई भी परीक्षा विफल होती है, तो हमें टेस्ट रन पुनः आरंभ करने की आवश्यकता नहीं है। परीक्षण के मिनट।

यह वही है जो मैंने कल शुरू किया था क्योंकि यह सरल और सीधा है और मुझे प्रगति करने की जरूरत है।

क्या आपने लेन-देन में परीक्षणों को लपेटने और ट्रंकट-ऑल-टेबल के तेजी से विकल्प के रूप में वापस रोल करने की रणनीति पर विचार किया है? यह मेरे लिए आदर्श की तरह लगता है, अगर मैं कार्यान्वयन का पता लगा सकता हूं।

मुझे लगता है कि यदि आप उसी प्रक्रिया में db और एप्लिकेशन कोड चलाते हैं, तो आप परीक्षण कोड में लेन-देन कर सकते हैं और फिर उस लेनदेन को अपने knex- उदाहरण के रूप में पंजीकृत कर सकते हैं (knex उदाहरण और लेनदेन कुछ मामलों में थोड़ा अलग दिखता है, लेकिन आमतौर पर आप लेनदेन का उपयोग कर सकते हैं सामान्य knex उदाहरण की तरह उदाहरण)।

फिर आप अपना एप्लिकेशन कोड शुरू करते हैं, जो सामान्य पूल किए गए नेक्स उदाहरण के बजाय लेन-देन प्राप्त करता है और उसी के माध्यम से प्रश्न करना शुरू करता है।

ओपी में वर्णित है कि बहुत ही उसी तरह। आपने बताया कि यह कैसे व्यवहार्य लगता है।

मैंने कुछ वर्षों पहले परीक्षणों में DB को रीसेट करने के लिए लेनदेन का उपयोग करने पर विचार किया है, लेकिन इसे अस्वीकार कर दिया है क्योंकि मैं परीक्षणों में काम करने के लिए पूलिंग को उसी तरह से जोड़ना चाहता हूं जिस तरह से यह ऐप + ट्रंकट / इनिट में काम करता है, हमारे लिए काफी तेज है।

क्या लेन-देन की अवधि के लिए संबंध आत्मीयता प्राप्त करने का कोई तरीका नहीं है, जैसे कि एक बैच में चलने वाले सभी प्रश्न एक ही कनेक्शन का उपयोग करेंगे, और इस तरह एक ही लेनदेन में शामिल होने योग्य होगा?

ट्रंकट रणनीति कार्य की तरह है, लेकिन यह बहुत ही क्रूर बल है। वर्तमान में मेरे पास प्रत्येक परीक्षण फ़ाइल में एक test.after.always () हुक है जो उस फ़ाइल में परीक्षणों से प्रभावित तालिकाओं (आमतौर पर प्रति फ़ाइल एक तालिका) को काटता है, लेकिन मैं उन किनारे के मामलों के बारे में सोच सकता हूं जो उस पर खराब हो जाएंगे।

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

अंत में, मैं अभी भी स्पष्ट नहीं हूं कि Knex में लेनदेन कैसे काम करता है। अगर मैं एक बनाने trx के साथ knex.transaction() होगा सभी प्रश्नों का उपयोग करके चलाए, trx स्वचालित रूप से लेन-देन का हिस्सा हो? क्या मुझे मैन्युअल रूप से / रोलबैक करना है? (नहीं फेंकी गई त्रुटियों को मानते हुए।)

क्या लेन-देन की अवधि के लिए संबंध आत्मीयता प्राप्त करने का कोई तरीका नहीं है, जैसे कि एक बैच में चलने वाले सभी प्रश्न एक ही कनेक्शन का उपयोग करेंगे, और इस तरह एक ही लेनदेन में शामिल होने योग्य होगा?

मुझे यह समझ में नहीं आया

ट्रंकट रणनीति कार्य की तरह है, लेकिन यह बहुत ही क्रूर बल है। वर्तमान में मेरे पास प्रत्येक परीक्षण फ़ाइल में एक test.after.always () हुक है जो उस फ़ाइल में परीक्षणों से प्रभावित तालिकाओं (आमतौर पर प्रति फ़ाइल एक तालिका) को काटता है, लेकिन मैं उन किनारे के मामलों के बारे में सोच सकता हूं जो उस पर खराब हो जाएंगे।

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

यहां तक ​​कि अगर आप अपने परीक्षण डेटा को रीसेट करने के लिए लेनदेन का उपयोग कर रहे हैं, तो आप सामान्य स्थिति में समानांतर में कई परीक्षण नहीं चला पाएंगे। आईडी क्रम अलग होंगे और लेनदेन गतिरोध आदि हो सकते हैं।

अंत में, मैं अभी भी स्पष्ट नहीं हूं कि Knex में लेनदेन कैसे काम करता है। यदि मैं knex.transaction () के साथ एक ट्रिक्स बनाता हूं, तो क्या ट्रक्स का उपयोग करके चलने वाले सभी प्रश्न स्वचालित रूप से लेनदेन का हिस्सा होंगे? क्या मुझे मैन्युअल रूप से / रोलबैक करना है? (नहीं फेंकी गई त्रुटियों को मानते हुए।)

यह एक प्रलेखन से पाया जाता है। यदि आप knex.transaction(callback) में कॉलबैक से वादा वापस नहीं करते हैं, तो आपको मैन्युअल रूप से प्रतिबद्ध / रोलबैक करने की आवश्यकता है। यदि कॉलबैक रिटर्न का वादा करता है, तो कमिट / रोलबैक स्वचालित रूप से कहा जाता है। आपके मामले में आपको संभवतः मैन्युअल रूप से रोलबैक करना होगा।

यहां तक ​​कि अगर आप अपने परीक्षण डेटा को रीसेट करने के लिए लेनदेन का उपयोग कर रहे हैं, तो आप सामान्य स्थिति में समानांतर में कई परीक्षण नहीं चला पाएंगे। आईडी क्रम अलग होंगे और लेनदेन गतिरोध आदि हो सकते हैं।

मैं प्रत्येक रिकॉर्ड के लिए रैंडमली आईडी बना रहा हूं। टकराव संभव है, लेकिन संभावना नहीं है, और अगर यह किसी दिन होता है, तो यह सिर्फ एक परीक्षा है - ग्राहक-सामना करने वाला कोड नहीं।

संक्षिप्त रूप में, मैं उन सभी प्रश्नों को मान रहा हूं, जिन्हें एक ही लेनदेन में समूहीकृत करने की आवश्यकता है, उसी DB कनेक्शन का उपयोग करना होगा, जिसे मैं अपना Knex पूल आकार सेट करके प्राप्त कर सकता हूं। 1. तब मुझे परीक्षणों को एक में करने की आवश्यकता होगी .serial संशोधक के साथ फ़ाइल धारावाहिक। हालांकि, मैं अभी भी परीक्षण फ़ाइलों के बीच संगामिति (जो प्रदर्शन के लिए सबसे महत्वपूर्ण कारक है), क्योंकि एवा एक अलग बच्चे प्रक्रिया में प्रत्येक परीक्षा फ़ाइल चलाता होगा।

मुझे लगता है कि मुझे इसे आज़माना चाहिए।

मैं इसे काम कर रहा हूँ!

https://gist.github.com/odigity/7f37077de74964051d45c4ca80ec3250

मैं अपने प्रोजेक्ट में यूनिट परीक्षण के लिए अवा का उपयोग कर रहा हूं, लेकिन इस उदाहरण के लिए, मैंने अवधारणा को प्रदर्शित करने के लिए हुक के पहले / बाद में एक मॉक यूनिट परीक्षण परिदृश्य बनाया।

हुक से पहले

• क्योंकि लेन-देन प्राप्त करना एक अतुल्यकालिक कार्रवाई है, मैं before हुक से वापस जाने के लिए एक नया वादा करता हूं और इसके resolve पद्धति पर कब्जा करता हूं, इसलिए इसे transaction() कॉलबैक में कहा जा सकता है।
• मैं एक लेन-देन खोलता हूं। कॉलबैक में, मैं ...
  
  
  
  • एक जगह पर tx हैंडल को सहेजें जो परीक्षण के लिए सुलभ होगा और after हुक
  
  
  • "परीक्षण ढांचे" को सूचित करने के लिए सहेजे गए resolve विधि को कॉल करें कि before हुक पूरा हो गया है, और परीक्षण शुरू हो सकता है
  
  

परीक्षण - मैं सहेजे गए tx हैंडल का उपयोग करके दो आवेषण क्वेरी निष्पादित करता हूं।

हुक के बाद - मैं लेनदेन को रोलबैक करने के लिए सहेजे गए tx हैंडल का उपयोग करता हूं, इस प्रकार परीक्षण के दौरान किए गए सभी परिवर्तनों को पूर्ववत करता है। चूंकि डेटा कभी भी प्रतिबद्ध नहीं होता है, इसलिए इसे अन्य परीक्षणों की गतिविधि के साथ देखा या हस्तक्षेप नहीं किया जा सकता है।

कंजेंसी पर

Knex

Knex आपको कनेक्शन पूल आकार के लिए विकल्प निर्दिष्ट करने देता है। यदि आपको एक ही कनेक्शन पर चलने वाले लेन-देन में सभी प्रश्नों को सुनिश्चित करने की आवश्यकता है (मेरा मानना ​​है कि हम ऐसा करते हैं), तो आप पूल आकार को 1 पर सेट करके इसे प्राप्त कर सकते हैं।

_But प्रतीक्षा करें ... स्रोत में इस टिप्पणी की जाँच करें:

// We need to make a client object which always acquires the same
// connection and does not release back into the pool.
function makeTxClient(trx, client, connection) {

अगर मैं इसे सही ढंग से समझता हूं, तो इसका मतलब है कि Knex को यह सुनिश्चित करने के लिए भरोसा किया जा सकता है कि लेनदेन में सभी प्रश्न एक ही कनेक्शन से गुजरते हैं, भले ही आपका पूल 1 से अधिक हो! इसलिए हमें अपने परिदृश्य के लिए इस विशेष डिग्री के बलिदान की आवश्यकता नहीं है।

BTW - डॉक्स को संभवतः इस आवश्यक और अद्भुत तथ्य को प्रतिबिंबित करना चाहिए।

अवा

_ मैं इस विशेष-विशेष को क्नेक्स-विशिष्ट के बजाय जानता हूं, लेकिन यह एक लोकप्रिय ढांचा है, और पाठ मोटे तौर पर ज्यादातर चौखटे पर लागू होते हैं_

अवा प्रत्येक टेस्टफ़ाइल को एक अलग प्रक्रिया में समवर्ती रूप से चलाता है। प्रत्येक प्रक्रिया के भीतर, यह सभी परीक्षणों को समवर्ती रूप से चलाता है। संगामिति के दोनों रूप --serial CLI विकल्प (जो सब कुछ क्रमबद्ध करते हैं) या .serial संशोधक का उपयोग test विधि पर किया जा रहा है (जो कि चिह्नित परीक्षणों को क्रमिक रूप से चलाने से पहले चिन्हित करता है) ) है।

लपेटें

जब मैंने इन सभी तथ्यों को एक साथ रखा:

• मैं प्रत्येक परीक्षण को लेन-देन में लपेट सकता हूं, जो सुनिश्चित करता है कि (क) परीक्षण डेटा (बी) के बिना टकराव या पुनरावृत्ति के बिना स्वत: पोस्ट-टेस्ट क्लीनअप किया जाए। वास्तव में, इस रणनीति का उपयोग करते हुए, मेरे परीक्षण डीबी का शाब्दिक रूप से कभी भी आवश्यक बीज डेटा के अलावा एक एकल रिकॉर्ड नहीं होगा।

• मैं अवा के इंटर-टेस्टीफाइल कॉन्सेप्ट से लाभ उठा सकता हूं, क्योंकि प्रत्येक टेस्टफाइल एक अलग प्रक्रिया में चलता है, और इस प्रकार इसका खुद क्नेक्स कनेक्शन पूल होगा।

• अगर मैं यह सुनिश्चित करूं कि मेरा कनेक्शन पूल है> = = फ़ाइल में परीक्षणों की संख्या। यह एक समस्या नहीं होनी चाहिए, मैंने एक भी फाइल में बड़ी संख्या में परीक्षण नहीं किए हैं, जो मैं वैसे भी बचने की कोशिश करता हूं। इसके अलावा, पूल को 1-10 जैसी सीमा के साथ सेट किया जा सकता है, इसलिए आप ऐसे कनेक्शन नहीं बना रहे हैं जिनकी आपको आवश्यकता नहीं है, लेकिन आपको हर बार जब आप एक परीक्षण जोड़ते हैं या निकालते हैं, तो आपको प्रत्येक परीक्षण फ़ाइल में एक स्थिर समायोजित नहीं करना पड़ता है।

अन्य लोगों के विचारों को प्राप्त करने के लिए उत्सुक, क्योंकि मैं एक ही समय में बड़ी संख्या में प्रौद्योगिकियों के चौराहे पर डबिंग कर रहा हूं जो मेरे लिए नए हैं ...

@odigity yup, knex में लेन-देन बहुत ही समर्पित कनेक्शन के लिए एक हैंडल है जहाँ knex स्वचालित रूप से BEGIN क्वेरी जोड़ देता है जब trx इंस्टेंस बनाया जाता है (वास्तव में SQL में लेन-देन आम तौर पर BEGIN से जुड़े उसी कनेक्शन पर जाने वाले प्रश्न हैं)।

यदि knex लेन-देन के लिए कनेक्शन आवंटित नहीं करेगा, तो लेनदेन बस काम नहीं करेगा।

Uuid कुंजियों का उपयोग करना या तो बुरा नहीं है, टकराव का परिवर्तन वास्तव में संभावना नहीं है जब तक कि वास्तव में कई पंक्तियाँ न हों। ("यदि आप 128-बिट UUID का उपयोग करते हैं, तो 'जन्मदिन का प्रभाव' हमें बताता है कि आपके द्वारा लगभग 2 ^ 64 कुंजी उत्पन्न करने के बाद टकराव की संभावना है, बशर्ते आपके पास प्रत्येक कुंजी में 128 बिट्स एन्ट्रॉपी हो।"

मुझे लगता है कि आपको अपने जवाब मिल गए, इसलिए इस 👍 को बंद करना

फिर से खोलने के लिए क्षमा करें, लेकिन मैं अब अप्रत्याशित व्यवहार देख रहा हूं। विशेष रूप से, यह तब काम कर रहा है जब इसे नहीं होना चाहिए, जिसका अर्थ है कि मेरी समझ को सही करने की आवश्यकता है।

यदि मैं पूल आकार को 1 पर सेट करता हूं, तो एक लेन-देन खोलें, फिर एक क्वेरी का उपयोग किए बिना इसे निष्पादित करें, यह समय से बाहर है क्योंकि यह एक कनेक्शन प्राप्त नहीं कर सकता है - जो समझ में आता है, क्योंकि उस कनेक्शन को पहले ही लेनदेन द्वारा लॉक कर दिया गया है।

हालाँकि, अगर मैं पूल का आकार 1 निर्धारित करता हूं और चार परीक्षण समवर्ती रूप से चलाता हूं, जिनमें से प्रत्येक:

• एक लेन-देन खोलता है
• प्रश्न चलाता है
• अंत में रोलबैक कहता है

वे सभी काम करते हैं। उन्हें काम नहीं करना चाहिए - कम से कम उनमें से कुछ को कनेक्शन की कमी से बाहर निकलना चाहिए - लेकिन वे हर बार ठीक काम करते हैं।

जब कोई कनेक्शन समय पर उपलब्ध नहीं हो तो क्या क्नेक्स ने प्रश्नों के लिए अंतर्निहित कतार बनाई है? यदि ऐसा है, तो गैर-टीएक्स क्वेरी को निष्पादित करने से पहले लेनदेन समाप्त होने की प्रतीक्षा करने के बजाय मेरा पहला उदाहरण क्यों विफल हो जाता है?

या Knex किसी भी तरह एक कनेक्शन पर कई समवर्ती लेनदेन मल्टीप्लेक्स करता है?

या क्नेक्स वास्तव में 2, 3, और 4 वें आह्वान पर उप-लेनदेन बना रहा है? यदि हां, तो यह शायद बेतरतीब ढंग से अपेक्षित परिणाम देगा ...

@odgity पहले मामले में आपके पास एप्लिकेशन साइड डेडलॉक है (आपका ऐप कनेक्शन और अधिग्रहण करने के इंतजार में फंस गया है)।

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

एकल कनेक्शन में मल्टीप्लेक्सिंग लेनदेन संभव नहीं है। घोंसले के लेनदेन को लेनदेन के अंदर सेवपॉइंट का उपयोग करके नेक्स द्वारा समर्थित किया जाता है। यदि आप पूल से नया लेन-देन करने के लिए कह रहे हैं जो या तो नहीं होगा।

धन्यवाद, यह वास्तव में उपयोगी है।

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

DEBUG = knex: * पर्यावरण चर के साथ अपना कोड चलाएँ और आप देखेंगे कि पूल क्या कर रहा है। क्नेक्स को पहले मामले में भी इंतजार करना चाहिए जब तक कि "मुझे कनेक्शन नहीं मिल सका" टाइमआउट हो। इसलिए यदि आपका लेन-देन दूसरा कनेक्शन प्राप्त होने तक प्रतीक्षा कर रहा है, तो यह आवेदन स्तर का गतिरोध है क्योंकि दोनों कनेक्शन प्रत्येक प्रतीक्षा कर रहे हैं (मुझे नहीं पता कि यह आपका मामला है)।

मुझे यह धागा बहुत उपयोगी लगा। यह देखकर अच्छा लगता है कि अन्य लोग भी टेस्ट लिखने की परवाह करते हैं जो सिस्टम राज्य को प्रदूषित नहीं करते हैं। मैंने एक परियोजना शुरू की जो लोगों को कोड के लिए परीक्षण लिखने की अनुमति देती है जो कि परीक्षण पूरा होने के बाद रोलबैक का उपयोग करता है।

https://github.com/bas080/knest

@ bas080 सामान्य मामले में, दृष्टिकोण उन चीजों को सीमित करता है जिन्हें आप परीक्षण कर सकते हैं (परीक्षण को केवल एकल लेनदेन का उपयोग करने की अनुमति देता है)। यह कई कोड / समवर्ती लेनदेन का उपयोग करने वाले परीक्षण कोड को रोक देगा। इसके अलावा, कोई कोड का परीक्षण नहीं कर सकता है जो निहित है (हालांकि बहुत सामान्य मामले नहीं) इस तरह से।

मुझे पता है कि परीक्षण चलाने के बाद राज्य को रीसेट करने के लिए लेन-देन का उपयोग करना बहुत सामान्य पैटर्न है, मैं जिस चीज पर जोर देना चाहता हूं वह यह है कि केवल उस दृष्टिकोण का उपयोग करने से किसी एक चीज का परीक्षण करने से रोकता है।

मैं प्रत्येक परीक्षण के बाद या डेटा को संशोधित करने वाले कुछ परीक्षणों के बाद डीबी को रौंदना और फिर से तैयार करना पसंद कर रहा हूं, जो एक-दूसरे पर निर्भर हैं (कुछ समय मैं प्रदर्शन कारणों से ऐसा करता हूं यदि आबादी 50ms से अधिक लंबी हो जाती है)।

हाय, इस मुद्दे को फिर से समझने के लिए खेद है, लेकिन मैं नई परियोजना शुरू कर दिया है जो नकली डेटा के साथ कई डेटाबेस के लिए knex के लिए एक cli है, _ मैं चाहूंगा कि आप इसे देखें और कुछ योगदान के साथ मेरी मदद करें

यूनिट टेस्टिंग के लिए, मैं केवल जाँच कर रहा हूँ कि मेरे SQL रैपर से Knex द्वारा निष्पादित क्वेरीज़ सही तरीके से बनाई गई हैं, क्वेरी चेन के अंत में toString() का उपयोग करके। एकीकरण परीक्षण के लिए, मैं पहले से ही ऊपर दी गई रणनीति को नियोजित कर रहा हूं - वह है: प्रत्येक परीक्षण से पहले रोलबैक -> माइग्रेट -> बीज। यदि आप अपने बीज डेटा को छोटा नहीं रख सकते हैं, लेकिन दूसरों के लिए उपयुक्त हो सकता है, तो बहुत कम हो सकता है।

वह चक्र है: रोलबैक -> माइग्रेट -> बीज, हर परीक्षण से पहले।

यह वास्तव में ऐसा करने का बुरा तरीका है। आगे और पीछे चलने वाले माइग्रेशन आसानी से सैकड़ों मिलीसेकंड ले जाते हैं, जो बहुत धीमी गति से होता है। आपको संपूर्ण परीक्षण सूट के लिए केवल एक बार माइग्रेशन चलाना चाहिए और फिर परीक्षण से पहले बस सभी तालिकाओं को काट देना चाहिए और परीक्षण परीक्षण डेटा को पॉप्युलेट करना चाहिए। यह रोलिंगबैक / पूरे स्कीमा को फिर से बनाने की तुलना में 100x आसानी से किया जा सकता है।

आप सभी टेबलों को आसानी से काट -छाँट करने के लिए

knexCleaner
    .clean(knex, { ignoreTables: ['knex_migrations', 'knex_migrations_lock'] })
    .then(() => knex.seed.run())

ध्यान दें कि यदि आप प्रत्येक टेस्ट सूट रन के प्रारंभ में माइग्रेशन चला रहे हैं तो ignoreTables भाग का उपयोग करने की कोई आवश्यकता नहीं है। यह केवल तभी आवश्यक है जब आप अपने परीक्षण डेटाबेस पर मैन्युअल रूप से माइग्रेशन चलाते हैं।

@ricardograca क्या यह विदेशी कुंजी के साथ मामलों को अच्छी तरह से संभालता है? (मतलब सफाई विफल नहीं होगी क्योंकि हटाने का आदेश गलत है)

यदि नहीं, तो इसे ठीक करना आसान है (बस एक ही प्रश्न के साथ सभी तालिकाओं को अलग करने की आवश्यकता है) :)

@elhigu आप ऐसा कैसे कर सकते हैं?

डेटाबेस पर निर्भर करता है, लेकिन उदाहरण के लिए इस तरह: https://github.com/Vincit/knex-db-manager/blob/master/lib/PostgresDatabaseManager.js#L95

@kibertoad हां, यह विदेशी प्रमुख बाधाओं को ठीक करता है और सब कुछ हटा देता है।

@odigity क्या होगा अगर हम उस तरह संरचना का परीक्षण करें:

// controller.js
const users = require('./usersModel.js');

module.exports.addUser = async ({ token, user }) => {
  // check token, or other logic
  return users.add(user);
};

// usersModel.js
const db = require('./db');

module.exports.add = async user => db('users').insert(user);

// db.js
module.exports = require('knex')({ /* config */});

मुझे लगता है कि आपके सभी कार्यों में अतिरिक्त क्वेरी होनी चाहिए (उदाहरण के लिए trx ) वास्तविक क्वेरी बिल्डरों में लेनदेन को पारित करने के लिए।
https://knexjs.org/#Builder -transacting

मुझे लगता है कि सही तरीका कुछ ऐसा होना चाहिए:

1. beforeEach में trx बनाएँ।
2. किसी तरह इसे इंजेक्ट करें। मेरे उदाहरण में require('./db') सॉल्ड रिटर्न ट्रक्स मूल्य।
3. परीक्षण करते हैं।
4. रोलबैक ट्रिक्स 'afterEach' में।

लेकिन, मुझे नहीं पता कि क्या यह ज्ञात है?
क्या होगा अगर कोड antoher लेनदेन का उपयोग करता है?

एक अन्य विकल्प: शायद कुछ फ़ंक्शन है जो क्वेरी को निष्पादित करना शुरू करता है। इसलिए हम इसे टेस्ट ट्रांजेक्शन में चलाने के लिए ओवरराइड कर सकते हैं।

पढ़ने के एक दिन के बाद knex कोड मैं इस दृष्टिकोण की कोशिश:

test.beforeEach(async t => {
    // if we use new 0.17 knex api knex.transaction().then - we can not handle rollback error
    // so we need to do it in old way
    // and add empty .catch to prevent unhandled rejection
    t.context.trx = await new Promise(resolve => db.transaction(trx => resolve(trx)).catch(() => {}));
    t.context.oldRunner = db.client.runner;
    db.client.runner = function(builder) {
        return t.context.oldRunner.call(t.context.trx.client, builder);
    };
    t.context.oldRaw = db.raw;
    db.raw = function(...args) {
        return t.context.oldRaw.call(this, ...args).transacting(t.context.trx);
    };
});

test.afterEach(async t => {
    db.raw = t.context.oldRaw;
    db.client.runner = t.context.oldRunner;
    await t.context.trx.rollback();
});

और यह थोड़े काम करता है। इसलिए मैं .raw और .client.runner विधियों को ओवरराइड करता हूं। .client.runner कॉल आंतरिक रूप से जब आप .then एक क्वेरी बिल्डर करते हैं। इस कार्य में db क् knex({ /* config */}) क्

@ निक्लेव जैसा कि मैंने पहले ही यहां बताया है; परीक्षण डेटा को रीसेट करने के लिए लेनदेन का उपयोग करना आमतौर पर एक बुरा विचार है और मैं इसे एक विरोधी पैटर्न के रूप में भी समझूंगा। तो knex internals ओवरराइड कर रहा है। हर परीक्षण पर या परीक्षण के सेट के लिए Truncate + repopulate db की सिफारिश की जाती है। यदि परीक्षण डेटा यथोचित आकार है, तो यह करने के लिए कई मिलीसेकंड नहीं लेता है।