परिचय

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

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

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

उदाहरण सिम्फनी वातावरण पर बनाया गया है और PHPUnit लाइब्रेरी का उपयोग किया गया है, लेकिन यह विचार किसी भी भाषा या ढांचे के लिए मान्य है।

परीक्षण करने के लिए कोड

आइए कल्पना करें कि हमारा एप्लिकेशन एक बाहरी एपीआई से जुड़ता है जो एक निर्दिष्ट तिथि के लिए बारिश की संभावना के बारे में डेटा लौटाता है। लौटाया गया डेटा इस तरह दिखता है:

{
   "date" : "2022-12-01",
   "rain_probability" : 0.75
}

अब, हमें वह डेटा लेना होगा और उसे इस मैपिंग के अनुसार वर्गीकृत करना होगा:

• बारिश_संभावना कम
• बारिश_संभावना ≥ 0.40 && बारिश_संभावना मध्यम
• बारिश_संभावना ≥ 0.75: उच्च

और परिणाम को निम्नलिखित इकाई द्वारा वर्णित डेटाबेस तालिका पर सहेजें:

#[ORM\Entity(repositoryClass: RainMeasure::class)]
class RainMeasure {

    #[ORM\Column]
    private string $date;

    #[ORM\Column]
    private float $probability;

    #[ORM\Column(length: 10)]
    private string $label;

    // Getters and setters
    // .......
}

आइए एक हैंडलर बनाएं जो बाहरी एपीआई डेटा प्राप्त करता है, बारिश की संभावना के अनुसार लेबल सेट करता है और इसे डेटाबेस में सहेजता है।

class RainMeassureHandler {
    private EntityManagerInterface $em;

    public function __construct(EntityManagerInterface $em)
    {
        $this->em = $em;
    }

    public function saveMeasure(array $measureData): void
    {
        if($measureData['rain_probability'] = 0.40 && $measureData['rain_probability'] setDate($measureData['date']);
        $rainMeasure->setProbability($measureData['rain_probability']);
        $rainMeasure->setLabel($label);

        $this->em->persist($rainMeasure);
        $this->em->flush();
    }
}

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

वियुग्मन व्यवहार का हम परीक्षण करना चाहते हैं

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

class RainMeasureLabelHandler 
{
    public function getLabelFromProbability(float $prob): string
    {
        if($prob = 0.40 && $prob 

और अब, हमारा रेनमेज़रहैंडलर इस तरह दिखेगा:


class RainMeasureHandler 
{
    private EntityManagerInterface $em;

    public function __construct(EntityManagerInterface $em)
    {
        $this->em = $em;
    }

    public function saveMeasure(array $measureData): void
    {
        $rainMeasureLabelHandler = new RainMeasureLabelHandler();
        $label = $rainMeasureLabelHandler->getLabelFromProbability($measureData['rain_probability']);

        $rainMeasure = new RainMeasure();
        $rainMeasure->setDate($measureData['date']);
        $rainMeasure->setProbability($measureData['rain_probability']);
        $rainMeasure->setLabel($label);

        $this->em->persist($rainMeasure);
        $this->em->flush();
    }
}




अब हम अपने RainMeasureLabelHandler के परीक्षण पर ध्यान केंद्रित कर सकते हैं जो हमारे डोमेन का हिस्सा होगा और बाहरी परतों पर कोई निर्भरता नहीं होगी। इसका परीक्षण करना उतना ही आसान होगा जितना दिखाया गया है:




  
  
  निष्कर्ष


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