परीक्षण के विभिन्न तरीके
पहले परिभाषित करें कि आप क्या कर रहे हैं: इकाई परीक्षण या एकीकरण परीक्षण । परतों की संख्या इकाई परीक्षण के लिए अप्रासंगिक है क्योंकि आप केवल एक वर्ग की सबसे अधिक संभावना का परीक्षण करते हैं। बाकी आप मजाक उड़ाते हैं। एकीकरण परीक्षण के लिए यह अपरिहार्य है कि आप कई परतों का परीक्षण करें। यदि आपके पास अच्छी यूनिट के परीक्षण हैं तो चाल को एकीकरण परीक्षणों को बहुत जटिल नहीं बनाना है।
यदि आपकी इकाई परीक्षण अच्छे हैं तो आपको एकीकरण परीक्षण करते समय सभी विवरणों का परीक्षण करने की आवश्यकता नहीं है।
हम जिन शब्दों का उपयोग करते हैं, वे थोड़े से प्लेटफ़ॉर्म पर निर्भर हैं, लेकिन आप उन्हें लगभग सभी परीक्षण / विकास प्लेटफार्मों में पा सकते हैं:
उदाहरण आवेदन
आप जिस तकनीक का उपयोग करते हैं उसके आधार पर नामों में अंतर हो सकता है, लेकिन मैं इसका उपयोग एक उदाहरण के रूप में करूंगा:
यदि आपके पास मॉडल उत्पाद, ProductsController और एक सूचकांक दृश्य के साथ एक साधारण CRUD अनुप्रयोग है जो उत्पादों के साथ एक HTML तालिका बनाता है:
एप्लिकेशन का अंतिम परिणाम उन सभी उत्पादों की सूची के साथ एक HTML तालिका दिखा रहा है जो सक्रिय हैं।
इकाई का परीक्षण
आदर्श
जिस मॉडल को आप काफी आसानी से परख सकते हैं। इसके लिए अलग-अलग तरीके हैं; हम जुड़नार का उपयोग करें। मुझे लगता है कि जिसे आप "नकली डेटासेट" कहते हैं। इसलिए प्रत्येक परीक्षण चलाने से पहले हम तालिका बनाते हैं, और मूल डेटा में डालते हैं। अधिकांश प्लेटफार्मों में इसके लिए तरीके हैं। उदाहरण के लिए, आपके परीक्षण वर्ग में, एक विधि सेटअप () जो प्रत्येक परीक्षण से पहले चलाया जाता है।
फिर हम अपना परीक्षण चलाते हैं, उदाहरण के लिए: testGetAllActive उत्पाद।
इसलिए हम सीधे एक परीक्षण डेटाबेस पर परीक्षण करते हैं। हम डेटा स्रोत का मजाक नहीं उड़ाते हैं; हम इसे हमेशा समान बनाते हैं। यह हमें उदाहरण के लिए डेटाबेस के नए संस्करण के साथ परीक्षण करने की अनुमति देता है, और कोई भी क्वेरी समस्याएँ आएंगी।
वास्तविक दुनिया में आप हमेशा 100% एकल जिम्मेदारी का पालन नहीं कर सकते हैं । यदि आप इसे और भी बेहतर करना चाहते हैं तो आप एक डेटा स्रोत का उपयोग कर सकते हैं, जिसका आप मजाक उड़ाते हैं। हमारे लिए (हम एक ORM का उपयोग करते हैं) जो पहले से मौजूद तकनीक का परीक्षण करने जैसा लगता है। इसके अलावा परीक्षण बहुत अधिक जटिल हो जाते हैं, और वे वास्तव में प्रश्नों का परीक्षण नहीं करते हैं। तो हम इसे इस तरह से रखते हैं।
हार्ड कोडित डेटा को अलग से जुड़नार में संग्रहीत किया जाता है। तो स्थिरता बनाने के लिए एक SQL फ़ाइल की तरह है जिसमें एक तालिका विवरण और हमारे द्वारा उपयोग किए जाने वाले रिकॉर्ड के लिए आवेषण है। हम उन्हें छोटा रखते हैं जब तक कि बहुत सारे रिकॉर्ड के साथ परीक्षण करने की वास्तविक आवश्यकता न हो।
class ProductModel {
public function getAllActive() {
return $this->find('all', array('conditions' => array('active' => 1)));
}
}
नियंत्रक
नियंत्रक को अधिक काम करने की आवश्यकता है, क्योंकि हम इसके साथ मॉडल का परीक्षण नहीं करना चाहते हैं। तो हम जो करते हैं वह है मॉडल का मजाक उड़ाना। इसका मतलब है: हम परीक्षण करते हैं: सूचकांक () विधि जो रिकॉर्ड की एक सूची वापस करना चाहिए।
इसलिए हम मॉडल मेथड getAllActive () को मॉक करते हैं और इसमें निश्चित डेटा (उदाहरण के लिए दो रिकॉर्ड) जोड़ते हैं। अब हम नियंत्रक को दृश्य में भेजे जाने वाले डेटा का परीक्षण करते हैं, और हम तुलना करते हैं कि क्या हम वास्तव में उन दो रिकॉर्डों को वापस प्राप्त करते हैं।
function testProductIndexLoggedIn() {
$this->setLoggedIn();
$this->ProductsController->mock('ProductModel', 'index', function(return array(your records) ));
$result=$this->ProductsController->index();
$this->assertEquals(2, count($result['products']));
}
बस काफी है। हम नियंत्रक के रूप में कम कार्यक्षमता जोड़ने की कोशिश करते हैं क्योंकि यह कठिन परीक्षण करता है। लेकिन निश्चित रूप से इसमें हमेशा कुछ कोड होता है। उदाहरण के लिए, हम आवश्यकताओं का परीक्षण करते हैं: यदि आप लॉग इन हैं तो केवल उन दो रिकॉर्ड को दिखाएं।
तो, नियंत्रक को सामान्य रूप से एक नकली और हार्डकोड डेटा का एक छोटा टुकड़ा चाहिए। एक लॉगिन प्रणाली के लिए शायद एक और एक। हमारे परीक्षण में हमारे पास इसके लिए एक सहायक विधि है: setLoggedIn ()। यह लॉगिन या बिना लॉगिन के साथ परीक्षण करना सरल बनाता है।
class ProductsController {
public function index() {
if($this->loggedIn()) {
$this->set('products', $this->ProductModel->getAllActive());
}
}
}
दृश्य
दृश्य परीक्षण कठिन है। पहले हम तर्क को अलग करते हैं जो दोहराता है। हम इसे हेल्पर्स में डालते हैं और उन कक्षाओं का कड़ाई से परीक्षण करते हैं। हम हमेशा एक ही आउटपुट की उम्मीद करते हैं। उदाहरण के लिए, generateHtmlTableFromArray ()।
फिर हमारे पास कुछ परियोजना विशिष्ट विचार हैं। हम उन का परीक्षण नहीं करते हैं। यह वास्तव में यूनिट परीक्षण करने के लिए वांछित नहीं है। हम उन्हें एकीकरण परीक्षणों के लिए रखते हैं। क्योंकि हमने बहुत सारे कोड को अपने विचार में निकाल लिया है, इसलिए हमारे यहाँ जोखिम कम है।
यदि आप हर बार जब आप HTML का एक टुकड़ा बदलते हैं, तो आपके परीक्षण बदलने की आवश्यकता होती है, जो कि अधिकांश परियोजनाओं के लिए उपयोगी नहीं है, तो आप उनका परीक्षण करना शुरू करते हैं।
echo $this->tableHelper->generateHtmlTableFromArray($products);
एकीकरण जांच
आपके द्वारा यहां दिए गए प्लेटफॉर्म के आधार पर आप उपयोगकर्ताओं की कहानियों आदि के साथ काम कर सकते हैं। इसे सेलेनियम या अन्य तुलनीय समाधानों की तरह वेबबेस किया जा सकता है ।
आम तौर पर हम बस डेटाबेस को जुड़नार के साथ लोड करते हैं और दावा करते हैं कि कौन सा डेटा उपलब्ध होना चाहिए। पूर्ण एकीकरण परीक्षण के लिए हम आम तौर पर बहुत वैश्विक आवश्यकताओं का उपयोग करते हैं। तो: उत्पाद को सक्रिय पर सेट करें और फिर देखें कि क्या उत्पाद उपलब्ध है।
हम सब कुछ फिर से परीक्षण नहीं करते हैं, जैसे कि सही फ़ील्ड उपलब्ध हैं। हम यहां बड़ी आवश्यकताओं का परीक्षण करते हैं। चूंकि हम नियंत्रक या दृश्य से हमारे परीक्षणों की नकल नहीं करना चाहते हैं। यदि कोई चीज आपके आवेदन के लिए या सुरक्षा कारणों से वास्तव में कुंजी / मुख्य भाग है (चेक पासवर्ड उपलब्ध नहीं है) तो हम उन्हें यह सुनिश्चित करने के लिए जोड़ते हैं कि यह सही है।
हार्ड कोडित डेटा को जुड़नार में संग्रहीत किया जाता है।
function testIntegrationProductIndexLoggedIn() {
$this->setLoggedIn();
$result=$this->request('products/index');
$expected='<table';
$this->assertContains($expected, $result);
// Some content from the fixture record
$expected='<td>Product 1 name</td>';
$this->assertContains($expected, $result);
}