Tests को प्रमाण के रूप में इस्तेमाल करें
पूरा हुआऐसी checks चुनें जो गलत व्यवहार अस्वीकार कर सकें। Generated tests का review generated implementation जितनी सावधानी से करें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंGenerated test authorization function का ऐसा mock बनाता है जो हमेशा access देता है। Test pass होने से क्या सिद्ध होता है?अभ्यास करें
आप क्या सीखेंगे
- हर महत्वपूर्ण requirement को सार्थक check से जोड़ें।
- Unit, integration और end-to-end प्रमाण का अंतर समझें।
- ऐसा test पहचानें जो implementation की वही गलत धारणा दोहराता है।
Requirement से शुरू करें
Tests विशिष्ट दावों के प्रमाण हैं। Test run सफल होने से software के हर गुण का प्रमाण नहीं मिलता। Tests माँगने से पहले जरूरी व्यवहार और हर check से पकड़ा जाने वाला दोष पहचानें।
काल्पनिक organization export में मुख्य requirement data isolation है। Organization A के उपयोगकर्ता को organization B के records नहीं मिलने चाहिए। केवल download सफल होने की जाँच करने वाला test यह requirement सिद्ध नहीं करता।
Agent से requirement और assertion का संबंध समझाने को कहें। इससे test suite बड़ा होने से पहले छूटे cases पहचानना आसान होता है।
Test का उचित दायरा चुनें
Unit test छोटे transformation को जल्दी जाँच सकता है। Integration test जाँच सकता है कि components साथ कैसे काम करते हैं। End-to-end test deployed या प्रतिनिधि application में उपयोगकर्ता की महत्वपूर्ण प्रक्रिया जाँच सकता है।
जरूरी प्रमाण देने वाला सबसे छोटा दायरा चुनें। Formatter के हर input के लिए पूरा browser test नहीं चाहिए। Authorization सीमा के लिए वास्तविक route और data access path जरूरी हो सकते हैं। महत्वपूर्ण browser interaction के लिए rendered interface का प्रमाण चाहिए।
| दावा | प्रमाण का उदाहरण |
|---|---|
| CSV output quote को सही escape करता है | Field में quote वाला unit test |
| दूसरी organization export नहीं पढ़ सकती | वास्तविक authorization से होकर जाने वाला integration test |
| Keyboard उपयोगकर्ता export शुरू कर सकता है | Browser test और manual keyboard review |
| Failed export उपयोगी error देता है | संबंधित interface पर failure path की जाँच |
Test types का कोई तय प्रतिशत हर system पर लागू नहीं होता। जिस विफलता को पहचानना है और check के रखरखाव की लागत के आधार पर चुनें।
एक ही गलत धारणा दोनों जगह होने से बचें
Agent एक ही गलत समझ से implementation और tests लिख सकता है। दोनों आपस में मेल खा सकते हैं, फिर भी requirement अधूरी रह सकती है।
मान लें implementation request में दी गई organization ID से records filter करता है। Test में signed-in user और request की ID समान है। Test pass हो जाता है। छूटा हुआ case वह उपयोगकर्ता है जो दूसरी organization की ID माँगता है।
उस case को वास्तविक trusted identity और authorization path के जरिए जोड़ें। हमेशा “अनुमति है” लौटाने वाला mock tenant isolation सिद्ध नहीं कर सकता। वह केवल authorization सफल होने के बाद का व्यवहार सिद्ध करता है।
जाँचें कि test fail हो सकता है
ज्ञात दोष के लिए नया regression test अलग branch में दोष वाले version पर चलाएँ। जाँचें कि वह इच्छित कारण से fail होता है। फिर सुधार लागू करें और test दोबारा चलाएँ।
Fixture load न होने के कारण fail हुआ test अभी business के व्यवहार का प्रमाण नहीं है। केवल exit code नहीं, विफलता का निरीक्षण करें।
व्यापक बदलावों में mutation testing से आकलन कर सकते हैं कि चुने हुए code changes tests को fail करते हैं या नहीं। इसकी लागत है और यह requirement review की जगह नहीं लेती। जहाँ अतिरिक्त प्रमाण किसी असर वाले निर्णय में मदद करे, वहाँ इसका उपयोग करें।
प्रमाण को बदलाव से जुड़ा रखें
अंतिम revision पर संबंधित checks चलाएँ। छोड़ी गई checks और उनके कारण दर्ज करें। Review में सुधार के बाद पुराने commit का परिणाम लागू न भी रहे।
Tests समझने योग्य रखें। महत्वपूर्ण शर्त छिपाने वाले बड़े helper के बजाय स्पष्ट setup और assertion चुनें। अलग विफलता पहचाने बिना रखरखाव का खर्च बढ़ाने वाली दोहराई checks हटा दें।
Reviewer बता सके कि tests क्या सिद्ध करते हैं और क्या अभी अनिश्चित है। यह व्याख्या tests की बड़ी संख्या से अधिक उपयोगी है।
अभ्यास करें
एक generated test चुनें। बताएँ कि वह कौन-सी requirement जाँचता है। अलग branch में अस्थायी रूप से संबंधित दोष जोड़ें। जाँचें कि test इच्छित कारण से fail होता है, फिर code वापस ठीक करें। लिखें कि test अब भी क्या cover नहीं करता।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।
स्रोत और आगे पढ़ें
- Google Engineering Practices: Review tests for useful assertions ↗
- Google Testing Blog: Test scope and feedback ↗