शुभ दोपहर मैं टेस्ट ऑटोमेशन में लगा हूं। सभी स्वचालन इंजीनियरों की तरह, मेरे पास पुस्तकालयों और उपकरणों का एक सेट है जो मैं आमतौर पर परीक्षण लिखने के लिए चुनता हूं। लेकिन समय-समय पर ऐसे हालात होते हैं जब कोई भी परिचित पुस्तकालय ऑटोटेस्ट को अस्थिर या नाजुक बनाने के जोखिम के साथ समस्या को हल नहीं कर सकता है। इस लेख में, मैं आपको यह बताना चाहूंगा कि mock'ov का उपयोग करने के प्रतीत होने वाले मानक कार्य ने मुझे अपने मॉड्यूल को लिखने के लिए कैसे प्रेरित किया। मैं अपने फैसले को साझा करना चाहता हूं और प्रतिक्रिया सुनना चाहता हूं।

आवेदन

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

तो, कल्पना कीजिए कि हमारे पास एक प्रणाली है जिसमें निम्नलिखित घटक हैं:

1. कॉन्फ़िगरेशन सर्वर। उपयोगकर्ता के लिए, यह एक एकल प्रविष्टि बिंदु है जहां वह न केवल सत्यापन के लिए आवेदन को कॉन्फ़िगर करता है, बल्कि सिस्टम के अन्य घटक भी।
2. सत्यापन का आवेदन।
3. आवेदन प्रसंस्करण अनुप्रयोगों से डेटा जो इलास्टिक्स खोज में संग्रहीत होते हैं।
4. संदर्भ डेटा। डेटा प्रारूप मैसेंजर पर निर्भर करता है जिसके साथ एप्लिकेशन एकीकृत है।

कार्य

इस मामले में परीक्षण स्वचालन काफी सीधा लगता है:

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

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

यहां यह सवाल उठ सकता है: "यदि हम अभी भी सर्वर का मजाक उड़ाते हैं, तो शायद हम इलास्टिक्स खोज को स्थापित करने और भरने में समय नहीं लगा सकते, लेकिन नकली की जगह ले सकते हैं?"। लेकिन फिर भी, आपको हमेशा याद रखने की आवश्यकता है कि मॉक का उपयोग लचीलापन प्रदान करता है, लेकिन मॉक के व्यवहार की प्रासंगिकता की निगरानी करने के लिए एक दायित्व जोड़ता है। इसलिए, मैंने इलास्टिक्स खोज को बदलने से इनकार कर दिया: इसे स्थापित करना और भरना काफी सरल है।

पहला मॉक

सर्वर कॉन्फ़िगरेशन को GET अनुरोधों को कई तरीकों से / कॉन्फ़िगरेशन में भेजता है। हम दो तरह से रुचि रखते हैं। पहला क्लस्टर कॉन्फ़िगरेशन के साथ /configuration/data_cluster है

 { "host": "127.0.0.1", "port": 443, "credentials": { "username": "user", "password": "pass" } } 

दूसरा है ड्रिलिंग एप्लिकेशन के कॉन्फ़िगरेशन के साथ /configuration/reconciliation

 { "reconciliation_interval": 3600, "configuration_update_interval": 60, "source": { "address": "file:///c:/path", "credentials": { "username": "user", "password": "pass" } } } 

कठिनाई यह है कि आपको परीक्षण के दौरान या परीक्षण के बीच सर्वर प्रतिक्रिया को बदलने के लिए सक्षम होना चाहिए ताकि एप्लिकेशन कॉन्फ़िगरेशन परिवर्तनों, गलत पासवर्ड आदि का जवाब दे सके।

तो, यूनिट परीक्षण में नकली के लिए स्थैतिक नकली और उपकरण (मॉक, पाइस्टेस्ट से बंदरपैक, आदि) हमारे लिए काम नहीं करेंगे। मुझे एक बड़ा pretenders पुस्तकालय मिला जो मुझे लगा कि मेरे लिए सही है। Pretenders नियमों के साथ एक HTTP सर्वर बनाने की क्षमता प्रदान करता है जो यह निर्धारित करता है कि सर्वर अनुरोधों का जवाब कैसे देगा। नियमों को प्रीसेट में संग्रहित किया जाता है, जो अलग-अलग परीक्षण सूट के लिए मोज़ेक को अलग करने की अनुमति देता है। प्रीसेट्स को साफ़ किया जा सकता है और फिर से भरा जा सकता है, जिससे आप आवश्यकतानुसार उत्तर अपडेट कर सकते हैं। पर्यावरण की तैयारी के दौरान सर्वर को एक बार स्वयं ही उठाना पर्याप्त है:

 python -m pretenders.server.server --host 127.0.0.1 --port 8000 

और परीक्षणों में हमें क्लाइंट के उपयोग को जोड़ने की आवश्यकता है। सरलतम मामले में, जब उत्तर परीक्षणों में पूरी तरह से हार्डकोडेड होते हैं, तो यह इस तरह दिख सकता है:

 import json import pytest from pretenders.client.http import HTTPMock from pretenders.common.constants import FOREVER @pytest.fixture def configuration_server_mock(request): mock = HTTPMock(host="127.0.0.1", port=8000, name="server") request.addfinalizer(mock.reset) return mock def test_something(configuration_server_mock): configuration_server_mock.when("GET /configuration/data_cluster").reply( headers={"Content-Type": "application/json"}, body=json.dumps({ "host": "127.0.0.1", "port": 443, "credentials": { "username": "user", "password": "pass", }, }), status=200, times=FOREVER, ) configuration_server_mock.when("GET /configuration/reconciliation").reply( headers={"Content-Type": "application/json"}, body=json.dumps({ "reconciliation_interval": 3600, "configuration_update_interval": 60, "source": { "address": "file:///c:/path", "credentials": { "username": "user", "password": "pass", }, }, }), status=200, times=FOREVER, ) # test application 

लेकिन यह सब नहीं है। अपने लचीलेपन के साथ, pretenders की दो सीमाएँ होती हैं जिन्हें याद रखना चाहिए और हमारे मामले में संबोधित किया जाना चाहिए:

1. नियमों को एक बार में हटाया नहीं जा सकता। उत्तर को बदलने के लिए, आपको पूरे पूर्व निर्धारित को हटाना होगा और सभी नियमों को फिर से बनाना होगा।
2. नियमों में उपयोग किए जाने वाले सभी पथ सापेक्ष हैं। प्रीसेट में फ़ॉर्म / mockhttp / <preset_name> का एक अनूठा पथ है, और यह पथ नियमों में सभी बनाए गए पथों के लिए एक सामान्य उपसर्ग है। परीक्षण के तहत आवेदन केवल मेजबान नाम प्राप्त करता है, और यह उपसर्ग के बारे में नहीं जान सकता है।

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

 configuration.data_cluster.port = 443 

या (अद्यतन अनुरोधों को कम बार करने के लिए)

 data_cluster_config = get_default_data_cluster_config() data_cluster_config.port = 443 configuration.update_data_cluster(data_cluster_config) 

इस तरह के एनकैप्सुलेशन से हम सभी रास्तों को लगभग दर्द रहित तरीके से अपडेट कर सकते हैं। आप प्रत्येक व्यक्ति के लिए प्रत्येक व्यक्तिगत समापन बिंदु और एक सामान्य (मुख्य) पूर्व निर्धारित, पुनर्निर्देशन (307 या 308 के माध्यम से) को अलग-अलग प्रीसेट भी बना सकते हैं। फिर आप नियम को अपडेट करने के लिए केवल एक पूर्व निर्धारित को साफ कर सकते हैं।

उपसर्गों से छुटकारा पाने के लिए, आप मितप्रोक्सी लाइब्रेरी का उपयोग कर सकते हैं। यह एक शक्तिशाली उपकरण है जो अन्य चीजों के साथ, अनुरोधों को पुनर्निर्देशित करने की अनुमति देता है। हम उपसर्गों को इस प्रकार निकालेंगे:

 mitmdump --mode reverse:http://127.0.0.1:8000 --replacements :~http:^/:/mockhttp/server/ --listen-host 127.0.01 --listen-port 80 

इस कमांड के पैरामीटर निम्नलिखित हैं:

1. --listen-host 127.0.0.1 और --listen-port 80 स्पष्ट हैं। मित्प्रॉक्सी अपने सर्वर को बढ़ाता है, और इन मापदंडों के साथ हम इंटरफ़ेस और पोर्ट का निर्धारण करते हैं जो यह सर्वर सुनता है।
2. --mode reverse:http://127.0.0.1:8000 अर्थ है कि मिटप्रोक्सी सर्वर के अनुरोधों को http://127.0.0.1:8000 पुनर्निर्देशित किया जाएगा। और पढ़ें यहाँ
3. --replacements :~http:^/:/mockhttp/server/ एक टेम्पलेट को परिभाषित करता है जिसके द्वारा अनुरोधों को बदला जाएगा। इसमें तीन भाग होते हैं: एक अनुरोध फ़िल्टर ( ~http HTTP अनुरोधों के लिए ~http ), (पथ की शुरुआत की जगह बदलने के लिए एक टेम्पलेट), और वास्तव में प्रतिस्थापित ( /mockhttp/server )। और पढ़ें यहाँ

हमारे मामले में, हम सभी HTTP अनुरोधों में mockhttp/server जोड़ते हैं और उन्हें http://127.0.0.1:8000 , अर्थात् पर पुनर्निर्देशित करते हैं। हमारे सर्वर के बहाने। नतीजतन, हमने यह हासिल कर लिया है कि अब विन्यास को GET के अनुरोध के साथ http://127.0.0.1/configuration/data_cluster प्राप्त किया जा सकता है।

सामान्य तौर पर, मैं mitmproxy और mitmproxy साथ डिजाइन से संतुष्ट था। स्पष्ट जटिलता के साथ - आखिरकार, एक वास्तविक एक के बजाय 2 सर्वर - तैयारी में 2 पैकेज स्थापित करने और उन्हें शुरू करने के लिए कमांड लाइन पर 2 कमांड निष्पादित करना शामिल है। एक मॉक को प्रबंधित करने में सब कुछ इतना सरल नहीं है, लेकिन सभी जटिलता केवल एक ही स्थान (प्रीसेट) का प्रबंधन करती है और इसे काफी सरलता से और विश्वसनीय तरीके से हल किया जाता है। हालाँकि, नई परिस्थितियों में समस्या सामने आई जिसने मुझे एक नए समाधान के बारे में सोचा।

दूसरा नकली

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

 GET /application-history?page=2&size=5&start=1569148012&end=1569148446 

यहां 2 बिंदु हैं। सबसे पहले, कुछ विकल्प। तथ्य यह है कि मापदंडों को किसी भी क्रम में निर्दिष्ट किया जा सकता है, जो pretenders शासन के लिए नियमित अभिव्यक्ति को बहुत जटिल करता है। यह याद रखना भी आवश्यक है कि पैरामीटर वैकल्पिक हैं, लेकिन यह यादृच्छिक क्रम जैसी समस्या नहीं है। दूसरे, अंतिम पैरामीटर (शुरू और अंत) आदेश को फ़िल्टर करने के लिए समय अंतराल निर्दिष्ट करते हैं। और इस मामले में समस्या यह है कि हम अग्रिम में अनुमान नहीं लगा सकते हैं कि कौन सा अंतराल (परिमाण नहीं, लेकिन प्रारंभ समय) का उपयोग आवेदन द्वारा नकली प्रतिक्रिया बनाने के लिए किया जाएगा। सीधे शब्दों में, हमें "उचित" उत्तर बनाने के लिए पैरामीटर मानों को जानना और उपयोग करना होगा। इस मामले में "उचितता" महत्वपूर्ण है, उदाहरण के लिए, ताकि हम यह परीक्षण कर सकें कि एप्लिकेशन पेजिंग के सभी पन्नों से गुजरता है: यदि हम सभी अनुरोधों का उसी तरह से उत्तर देते हैं, तो हम इस तथ्य के कारण दोषों को खोजने में सक्षम नहीं होंगे, केवल पांच में से केवल एक पृष्ठ का अनुरोध किया गया है। ।

मैंने वैकल्पिक समाधान खोजने की कोशिश की, लेकिन अंत में मैंने खुद लिखने की कोशिश करने का फैसला किया। तो एक ढीला सर्वर था । यह एक फ्लास्क एप्लिकेशन है जिसमें पथ और प्रतिक्रियाओं को शुरू होने के बाद कॉन्फ़िगर किया जा सकता है। बॉक्स से बाहर, वह जानता है कि अनुरोध के प्रकार (GET, POST, आदि) और पथ के लिए नियमों के साथ कैसे काम किया जाए। यह आपको मूल कार्य में pretenders और mitmproxy को बदलने की अनुमति देता है। मैं यह भी दिखाऊंगा कि इसका उपयोग विक्रेता एपीआई के लिए नकली बनाने के लिए कैसे किया जा सकता है।

एक आवेदन के लिए 2 मुख्य रास्ते चाहिए:

1. आधार समापन बिंदु। यह वही उपसर्ग है जो सभी कॉन्फ़िगर नियमों के लिए उपयोग किया जाएगा।
2. कॉन्फ़िगरेशन समापन बिंदु। यह उन अनुरोधों का उपसर्ग है, जिनके साथ आप स्वयं मॉक सर्वर को कॉन्फ़िगर कर सकते हैं।

 python -m looseserver.default.server.run --host 127.0.0.1 --port 80 --base-endpoint / --configuration-endpoint /_mock_configuration/ 

सामान्य तौर पर, बेस एंडपॉइंट और कॉन्फ़िगरेशन एंडपॉइंट को कॉन्फ़िगर नहीं करना सबसे अच्छा है ताकि एक दूसरे के माता-पिता हो। अन्यथा, एक जोखिम है कि कॉन्फ़िगरेशन के लिए और परीक्षण के लिए पथ संघर्ष होगा। कॉन्फ़िगरेशन समापन बिंदु पूर्ववर्तीता ले जाएगा, क्योंकि फ्लास्क नियम कॉन्फ़िगरेशन के लिए डायनामिक पथों की तुलना में पहले जोड़े गए हैं। हमारे मामले में, हम उपयोग कर सकते हैं --base-endpoint /configuration/ यदि हम इस मॉक में विक्रेता एपीआई को शामिल नहीं करने जा रहे थे।

परीक्षणों का सबसे सरल संस्करण बहुत कुछ नहीं बदलता है

 import json import pytest from looseserver.default.client.http import HTTPClient from looseserver.default.client.rule import PathRule from looseserver.default.client.response import FixedResponse @pytest.fixture def configuration_server_mock(request): class MockFactory: def __init__(self): self._client = HTTPClient(configuration_url="http://127.0.0.1/_mock_configuration/") self._rule_ids = [] def create_rule(self, path, json_response): rule = self._client.create_rule(PathRule(path=path)) self._rule_ids.append(rule.rule_id) response = FixedResponse( headers={"Content-Type": "application/json"}, status=200, body=json.dumps(json_response), ) self._client.set_response(rule_id=rule.rule_id, response=response) def _delete_rules(self): for rule_id in self._rule_ids: self._client.remove_rule(rule_id=rule_id) mock = MockFactory() request.addfinalizer(mock._delete_rules) return mock def test_something(configuration_server_mock): configuration_server_mock.create_rule( path="configuration/data_cluster", json_response={ "host": "127.0.0.1", "port": 443, "credentials": { "username": "user", "password": "pass", }, } ) configuration_server_mock.create_rule( path="configuration/reconciliation", json_response={ "reconciliation_interval": 3600, "configuration_update_interval": 60, "source": { "address": "file:///applications", "credentials": { "username": "user", "password": "pass", }, }, } ) 

स्थिरता अधिक कठिन हो गई है, लेकिन नियमों को अब एक बार में हटा दिया जा सकता है, जो उनके साथ काम को सरल करता है। mitmproxy उपयोग करने की अब आवश्यकता नहीं है।

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

सर्वर और क्लाइंट दोनों के लिए नए नियम और उत्तर बनाए जाने की आवश्यकता है। आइए सर्वर से शुरू करें:

 from looseserver.server.rule import ServerRule class ServerParameterRule(ServerRule): def __init__(self, parameter_name, parameter_value=None, rule_type="PARAMETER"): super(ServerParameterRule, self).__init__(rule_type=rule_type) self._parameter_name = parameter_name self._parameter_value = parameter_value def is_match_found(self, request): if self._parameter_value is None: return self._parameter_name not in request.args return request.args.get(self._parameter_name) == self._parameter_value 

प्रत्येक नियम को एक is_match_found विधि परिभाषित करनी चाहिए, जो यह निर्धारित करती है कि उसे दिए गए अनुरोध के लिए काम करना चाहिए या नहीं। इसके लिए इनपुट पैरामीटर अनुरोध ऑब्जेक्ट है। नया नियम बनने के बाद, आपको क्लाइंट से इसे स्वीकार करने के लिए सर्वर को "सिखाने" की आवश्यकता है। ऐसा करने के लिए, RuleFactory उपयोग RuleFactory :

 from looseserver.default.server.rule import create_rule_factory from looseserver.default.server.application import configure_application def _create_application(base_endpoint, configuration_endpoint): server_rule_factory = create_rule_factory(base_endpoint) def _parse_param_rule(rule_type, parameters): return ServerParameterRule( rule_type=rule_type, parameter_name=parameters["parameter_name"], parameter_value=parameters["parameter_value"], ) server_rule_factory.register_rule( rule_type="PARAMETER", parser=_parse_param_rule, serializer=lambda rule_type, rule: None, ) return configure_application( rule_factory=server_rule_factory, base_endpoint=base_endpoint, configuration_endpoint=configuration_endpoint, ) if __name__ == "__main__": application = _create_application(base_endpoint="/", configuration_endpoint="/_mock_configuration") application.run(host="127.0.0.1", port=80) 

यहां हम डिफ़ॉल्ट रूप से नियमों के लिए एक कारखाना बनाते हैं, ताकि इसमें वे नियम शामिल हों जो हमने पहले उपयोग किए थे, और एक नया प्रकार पंजीकृत करें। इस मामले में, क्लाइंट को नियम की जानकारी की आवश्यकता नहीं है, इसलिए serializer वास्तव में कुछ भी नहीं करता है। इसके अलावा इस कारखाने को आवेदन में स्थानांतरित कर दिया जाता है। और यह पहले से ही एक नियमित फ्लास्क एप्लिकेशन की तरह चलाया जा सकता है।

क्लाइंट के साथ स्थिति समान है: हम एक नियम और एक कारखाना बनाते हैं। लेकिन क्लाइंट के लिए, सबसे पहले, यह is_match_found पद्धति को परिभाषित करने के लिए आवश्यक नहीं है, और दूसरी बात, इस मामले में धारावाहिक को नियम को सर्वर पर भेजने के लिए आवश्यक है।

 from looseserver.client.rule import ClientRule from looseserver.default.client.rule import create_rule_factory class ClientParameterRule(ClientRule): def __init__(self, parameter_name, parameter_value=None, rule_type="PARAMETER", rule_id=None): super(ClientParameterRule, self).__init__(rule_type=rule_type, rule_id=rule_id) self.parameter_name = parameter_name self.parameter_value = parameter_value def _create_client(configuration_url): def _serialize_param_rule(rule): return { "parameter_name": rule.parameter_name, "parameter_value": rule.parameter_value, } client_rule_factory = create_rule_factory() client_rule_factory.register_rule( rule_type="PARAMETER", parser=lambda rule_type, parameters: ClientParameterRule(rule_type=rule_type, parameter_name=None), serializer=_serialize_param_rule, ) return HTTPClient(configuration_url=configuration_url, rule_factory=client_rule_factory) 

यह ग्राहक बनाने के लिए _create_client का उपयोग करने के लिए बनी हुई है, और नियमों का उपयोग परीक्षणों में किया जा सकता है। नीचे दिए गए उदाहरण में, मैंने एक और डिफ़ॉल्ट नियम का उपयोग जोड़ा: CompositeRule । यह आपको कई नियमों को एक में संयोजित करने की अनुमति देता है ताकि वे केवल तभी काम करें जब उनमें से प्रत्येक ट्रू के लिए सही है।

 @pytest.fixture def configuration_server_mock(request): class MockFactory: def __init__(self): self._client = _create_client("http://127.0.0.1/_mock_configuration/") self._rule_ids = [] def create_paged_rule(self, path, page, json_response): rule_prototype = CompositeRule( children=[ PathRule(path=path), ClientParameterRule(parameter_name="page", parameter_value=page), ] ) rule = self._client.create_rule(rule_prototype) self._rule_ids.append(rule.rule_id) response = FixedResponse( headers={"Content-Type": "application/json"}, status=200, body=json.dumps(json_response), ) self._client.set_response(rule_id=rule.rule_id, response=response) ... mock = MockFactory() request.addfinalizer(mock._delete_rules) return mock def test_something(configuration_server_mock): ... configuration_server_mock.create_paged_rule( path="application-history", page=None, json_response=["1", "2", "3"], ) configuration_server_mock.create_paged_rule( path="application-history", page="1", json_response=["1", "2", "3"], ) configuration_server_mock.create_paged_rule( path="application-history", page="2", json_response=["4", "5"], ) 

निष्कर्ष

mitmproxy और mitmproxy pretenders एक mitmproxy बनाने के लिए एक शक्तिशाली और लचीला पर्याप्त उपकरण प्रदान करता है। इसके फायदे:

1. आसान सेटअप।
2. प्रीसेट का उपयोग करके क्वेरी सेट को अलग करने की क्षमता।
3. एक बार में एक पूरे पृथक सेट को हटाता है।

विपक्ष में शामिल हैं:

1. नियमों के लिए नियमित अभिव्यक्ति बनाने की आवश्यकता।
2. नियमों को व्यक्तिगत रूप से बदलने में असमर्थता।
3. सभी निर्मित रास्तों के लिए एक उपसर्ग की उपस्थिति या mitmproxy का उपयोग करके पुनर्निर्देशन का उपयोग mitmproxy ।

दस्तावेज़ लिंक:
उम्मीदवार
Mitmproxy
ढीला सर्वर