कुछ आदेश में PHPUnit टेस्ट चलाएं

क्या किसी निश्चित क्रम में चलाने के लिए TestCase के अंदर परीक्षण प्राप्त करने का कोई तरीका है? उदाहरण के लिए, मैं किसी ऑब्जेक्ट के जीवन चक्र को निर्माण से विनाश के लिए अलग करना चाहता हूं लेकिन मुझे यह सुनिश्चित करने की ज़रूरत है कि अन्य परीक्षण चलाने से पहले ऑब्जेक्ट पहले स्थापित हो।

0
ro fr bn
एक अतिरिक्त उपयोग-मामला जो कवर नहीं किया गया प्रतीत होता है: शायद सभी परीक्षण परमाणु हैं, लेकिन कुछ परीक्षण धीमे हैं। मैं तेजी से परीक्षणों को एएसएपी चलाने के लिए चाहता हूं ताकि वे तेजी से असफल हो सकें, और आखिरकार अन्य समस्याओं को देखने के बाद और धीमे परीक्षणों को अंतिम रूप से चलाया जा सकता है और उन्हें तुरंत मिल सकता है।
जोड़ा लेखक Kzqai, स्रोत
आप नीचे दिए गए उत्तर में वर्णित अनुसार @depends जोड़ सकते हैं, और सेटअप() और टियरडाउन() का उपयोग करना भी एक अच्छा विचार है, लेकिन परीक्षण केवल नीचे से नीचे चलाए जाते हैं ...
जोड़ा लेखक Andrew, स्रोत

8 उत्तर

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

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

0
जोड़ा
PHPUnit @depends के माध्यम से परीक्षण निर्भरताओं का समर्थन करता है।
जोड़ा लेखक mjs, स्रोत

शायद आपके परीक्षणों में एक डिजाइन समस्या है।

आम तौर पर प्रत्येक परीक्षण किसी अन्य परीक्षण पर निर्भर नहीं होना चाहिए, इसलिए वे किसी भी क्रम में चल सकते हैं।

प्रत्येक परीक्षण को चलाने के लिए आवश्यक सभी चीज़ों को तुरंत और नष्ट करने की आवश्यकता होती है, यह एक आदर्श दृष्टिकोण होगा, आपको परीक्षणों के बीच वस्तुओं और राज्यों को कभी साझा नहीं करना चाहिए।

क्या आप एन परीक्षणों के लिए एक ही वस्तु की आवश्यकता के बारे में अधिक विशिष्ट हो सकते हैं?

0
जोड़ा
यदि निर्माता जटिल है तो आप कुछ गलत कर रहे हैं, शायद आपकी कक्षा बहुत अधिक कर रही है। कृपया "सॉलिड" के बारे में पढ़ें, "एकल उत्तरदायित्व पैटर्न (एसआरपी)" के बारे में अधिक विशिष्ट, आपको मॉक्स का उपयोग करके अपने परीक्षणों में निर्भरता को "नकली" करना चाहिए, कृपया "मॉक्स, नकली और स्टब्स" के बारे में भी पढ़ें।
जोड़ा लेखक Fabio Gomes, स्रोत
एक व्यावहारिक कारण भी हो सकता है। उदाहरण के लिए, यदि आपको जिस सफाई की आवश्यकता है वह कणिक रूप से समय लेने वाला है, तो आप इसे केवल एक बार चलाने के लिए tearDownAfterClass फ़ंक्शन का उपयोग कर सकते हैं। यदि एक विशेष परीक्षण के लिए एक साफ स्लेट की आवश्यकता होती है, तो आपको या तो यह सुनिश्चित करना होगा कि परीक्षण पहले चलाया जाए, या मैन्युअल रूप से tearDownAfterClass फ़ंक्शन को इसकी शुरुआत में कॉल करें, जिससे इसे दो बार चलाया जा सकता है। हां, यह शायद एक संकेत है कि टेस्ट क्लास डिज़ाइन में कुछ गड़बड़ है, लेकिन वैध मामले हैं जहां ऑर्डरिंग परीक्षण उपयोगी है।
जोड़ा लेखक Benubird, स्रोत
यह मेरे लिए सही प्रतीत नहीं होता है। यूनिट टेस्ट का बिंदु एक संपूर्ण इकाई का परीक्षण करना है। एक इकाई रखने का मुद्दा चीजों को एक साथ समूह करना है जिसे एक दूसरे पर निर्भर होना है। कक्षाओं के संदर्भ के बिना व्यक्तिगत तरीकों का परीक्षण करने वाले परीक्षणों को लिखना ओओ पर प्रक्रियात्मक प्रोग्रामिंग की वकालत करना है क्योंकि आप वकालत कर रहे हैं कि व्यक्तिगत कार्यों को उसी डेटा पर निर्भर नहीं होना चाहिए।
जोड़ा लेखक doliver, स्रोत
मैं आपके दृष्टिकोण से असहमत हूं। एक तत्काल परीक्षण का आउटपुट एक वैध वस्तु है जिसका प्रयोग आपके परीक्षण सूट में अन्य परीक्षणों द्वारा किया जा सकता है। प्रत्येक परीक्षण के लिए एक नई वस्तु को तत्काल करने की आवश्यकता नहीं है, विशेष रूप से यदि निर्माता जटिल है।
जोड़ा लेखक pedromanoel, स्रोत
कम से कम डेटाबेस परीक्षण पुन: उपयोग करने वाली वस्तुओं (कम से कम कनेक्शन) के लिए अक्सर आवश्यक है। PHPUnit उस संदर्भ को भी संदर्भित करता है: phpunit.de/manual/current/en/database.html (देखें: युक्ति: अपना स्वयं का सार डेटाबेस टेस्टकेस का उपयोग करें)
जोड़ा लेखक emfi, स्रोत
@emfi अगर आप फिर से एक वास्तविक डेटाबेस का परीक्षण कर रहे हैं, तो आप इकाई परीक्षण नहीं कर रहे हैं। आप कार्यात्मक परीक्षण कर रहे हैं। यूनिट परीक्षण करने के लिए, आपको डीबी एडाप्टर का नकल करना होगा और, जैसा कि फैबियो कहते हैं, आपको प्रत्येक टेस्ट-रन पर अपने एसयूटी (सिस्टम अंडर टेस्ट) को तुरंत चालू करने की आवश्यकता है। यदि आप प्रत्येक टेस्ट के लिए दोहराने जा रहे हैं तो आप मोक्स तैयार करने के लिए संरक्षित setUp() विधि का उपयोग कर सकते हैं।
जोड़ा लेखक Xavi Montero, स्रोत

मेरे विचार में, निम्नलिखित परिदृश्य लें जहां मुझे सृजन का परीक्षण करने और किसी विशेष संसाधन को नष्ट करने की आवश्यकता है।

शुरू में मेरे पास दो विधियां थीं, ए। testCreateResource और बी। testDestroyResource

ए। testCreateResource

<?php
$app->createResource('resource');
$this->assertTrue($app->hasResource('resource'));
?>

ख। testDestroyResource

<?php
$app->destroyResource('resource');
$this->assertFalse($app->hasResource('resource'));
?>

मुझे लगता है कि यह एक बुरा विचार है, क्योंकि testDestroyResource testCreateResource पर निर्भर करता है। और एक बेहतर अभ्यास करना होगा

ए। testCreateResource

<?php
$app->createResource('resource');
$this->assertTrue($app->hasResource('resource'));
$app->deleteResource('resource');
?>

ख। testDestroyResource

<?php
$app->createResource('resource');
$app->destroyResource('resource');
$this->assertFalse($app->hasResource('resource'));
?>
0
जोड़ा
-1 आपके दूसरे दृष्टिकोण में, नष्ट संसाधन संसाधन बनाने पर निर्भर करता है, लेकिन यह स्पष्ट रूप से इस तरह सेट नहीं है। यदि CreateResource विफल हो जाता है, तो UTesting Framework गलत तरीके से इंगित करेगा कि नष्ट करें संसाधन संसाधन काम नहीं कर रहा है
जोड़ा लेखक Tivie, स्रोत

PHPUnit @ निर्भर करता है एनोटेशन।

यहां दस्तावेज़ीकरण का एक उदाहरण दिया गया है जहां परीक्षण निर्भरता को पूरा करने वाले क्रम में चलाए जाएंगे, प्रत्येक आश्रित परीक्षण अगले को तर्क दे रहा है:

class StackTest extends PHPUnit_Framework_TestCase
{
    public function testEmpty()
    {
        $stack = array();
        $this->assertEmpty($stack);

        return $stack;
    }

    /**
     * @depends testEmpty
     */
    public function testPush(array $stack)
    {
        array_push($stack, 'foo');
        $this->assertEquals('foo', $stack[count($stack)-1]);
        $this->assertNotEmpty($stack);

        return $stack;
    }

    /**
     * @depends testPush
     */
    public function testPop(array $stack)
    {
        $this->assertEquals('foo', array_pop($stack));
        $this->assertEmpty($stack);
    }
}

हालांकि, यह ध्यान रखना महत्वपूर्ण है कि अनसुलझे निर्भरताओं के साथ परीक्षण नहीं निष्पादित किए जाएंगे (वांछनीय, क्योंकि यह असफल परीक्षण पर तुरंत ध्यान देता है)। इसलिए, निर्भरताओं का उपयोग करते समय ध्यान देना महत्वपूर्ण है।

0
जोड़ा
@Dereckson पर विस्तार करने के लिए, @depends एनोटेशन एक परीक्षण को छोड़ देगा यदि या तो पर निर्भर परीक्षण अभी तक चलाया गया है या विफल नहीं हुआ है भाग गया
जोड़ा लेखक ogc-nick, स्रोत
परीक्षण आदेश के साथ समस्या का समाधान नहीं करता है
जोड़ा लेखक Gino Pane, स्रोत
PHPUnit के लिए, इसका मतलब है कि पिछले परीक्षण निष्पादित नहीं किए जाने पर परीक्षण फ़ंक्शन छोड़ा जाएगा। यह एक परीक्षण आदेश नहीं बनाता है।
जोड़ा लेखक Dereckson, स्रोत

दूसरा तरीका: पुन: प्रयोज्य तत्व बनाने के लिए अपने परीक्षणों में स्थिर (!) फ़ंक्शंस का उपयोग करें। उदाहरण के लिए (मैं ब्राउज़र के अंदर परीक्षण चलाने के लिए परीक्षण और phpunit-selenium (github) रिकॉर्ड करने के लिए सेलेनियम आईडीई का उपयोग करता हूं)

class LoginTest extends SeleniumClearTestCase
{
    public function testAdminLogin()
    {
        self::adminLogin($this);
    }

    public function testLogout()
    {
        self::adminLogin($this);
        self::logout($this);
    }

    public static function adminLogin($t)
    {
        self::login($t, '[email protected]', 'pAs$w0rd');
        $t->assertEquals('John Smith', $t->getText('css=span.hidden-xs'));
    }

   //@source LoginTest.se
    public static function login($t, $login, $pass)
    {
        $t->open('/');
        $t->click("xpath=(//a[contains(text(),'Log In')])[2]");
        $t->waitForPageToLoad('30000');
        $t->type('name=email', $login);
        $t->type('name=password', $pass);
        $t->click("//button[@type='submit']");
        $t->waitForPageToLoad('30000');
    }

   //@source LogoutTest.se
    public static function logout($t)
    {
        $t->click('css=span.hidden-xs');
        $t->click('link=Logout');
        $t->waitForPageToLoad('30000');
        $t->assertEquals('PANEL', $t->getText("xpath=(//a[contains(text(),'Panel')])[2]"));
    }
}

ठीक है, और अब, मैं अन्य पुन: प्रयोज्य तत्वों को अन्य परीक्षण में उपयोग कर सकता हूं :) उदाहरण के लिए:

class ChangeBlogTitleTest extends SeleniumClearTestCase
{
    public function testAddBlogTitle()
    {
      self::addBlogTitle($this,'I like my boobies');
      self::cleanAddBlogTitle();
    }

    public static function addBlogTitle($t,$title) {
      LoginTest::adminLogin($t);

      $t->click('link=ChangeTitle');
      ...
      $t->type('name=blog-title', $title);
      LoginTest::logout($t);
      LoginTest::login($t, '[email protected]','hilton');
      $t->screenshot();//take some photos :)
      $t->assertEquals($title, $t->getText('...'));
    }

    public static function cleanAddBlogTitle() {
        $lastTitle = BlogTitlesHistory::orderBy('id')->first();
        $lastTitle->delete();
    }
  • इस तरह, आप परीक्षणों का पदानुक्रम बना सकते हैं।
  • आप स्टील को संपत्ति रख सकते हैं कि प्रत्येक टेस्ट केस दूसरे से अलग है (यदि आप प्रत्येक परीक्षण के बाद डीबी साफ़ करते हैं)।
  • और सबसे महत्वपूर्ण, उदाहरण के लिए, भविष्य में लॉगिन परिवर्तन का तरीका, आप केवल लॉगिनटेस्ट क्लास को संशोधित करते हैं, और आपको अन्य परीक्षणों में सही लॉगिन भाग की आवश्यकता नहीं है (उन्हें लॉगिनटेस्ट अपडेट के बाद काम करना चाहिए):

मैं परीक्षण चलाते हैं मेरी स्क्रिप्ट डाटाबेस विज्ञापन शुरुआत को साफ। ऊपर मैं अपने का उपयोग SeleniumClearTestCase वर्ग इसके बारे में विस्तार है (मैं वहाँ स्क्रीनशॉट() और अन्य अच्छा काम करता है बनाने के) MigrationToSelenium2 बंदरगाह seleniumIDE का उपयोग कर फ़ायरफ़ॉक्स में परीक्षण दर्ज की गई (GitHub से, करने के लिए + एफएफ प्लगइन "सेलेनियम आईडीई: पीएचपी formatters") जो मेरी कक्षा LaravelTestCase का विस्तार है (यह रोशन \ फाउंडेशन \ परीक्षण \ testcase की प्रतिलिपि है, लेकिन नहीं फैली PHPUnit_Framework_TestCase) जो सेटअप laravel वाक्पटु की पहुंच है जब हम पर डीबी साफ करने के लिए चाहते हैं परीक्षण के अंत) जो PHPUnit_Extensions_Selenium2TestCase का विस्तार है। laravel वाक्पटु सेट करने के लिए मैं SeleniumClearTestCase समारोह createApplication में भी है (जो सेटअप पर कहा जाता है, और मैं laral परीक्षा/testcase से इस समारोह लेने के लिए)

0
जोड़ा
लैरवेल 5.2 और सेल्फ़ियम आईडीई में सेलेनियम आईडीई में दर्ज परीक्षण चलाने के लिए यहां अधिक जानकारी दी गई है: stackoverflow.com/questions/33845828/…
जोड़ा लेखक Kamil Kiełczewski, स्रोत

इसके लिए सही उत्तर परीक्षणों के लिए एक उचित विन्यास फाइल है। मुझे एक ही समस्या थी और आवश्यक टेस्ट फाइल ऑर्डर के साथ टेस्टाइट बनाने के द्वारा इसे ठीक किया गया था:

phpunit.xml:


    
        
            file1 //this will be run before file2
            file2 //this depends on file1
        
    

0
जोड़ा
मुझे लगता है कि यह एकमात्र विश्वसनीय समाधान है
जोड़ा लेखक emfi, स्रोत

यदि आप अपने परीक्षणों को विभिन्न सहायक वस्तुओं और सेटिंग्स को साझा करना चाहते हैं, तो आप setFown() , sharedFownxture प्रॉपर्टी में जोड़ने के लिए setUp() , tearDown() का उपयोग कर सकते हैं ।

0
जोड़ा
क्या आप अभी भी setUp() में assertEquals() , आदि कर सकते हैं? क्या यह बुरा अभ्यास है?
जोड़ा लेखक jchook, स्रोत

PHPUnit '@depends' एनोटेशन के उपयोग की अनुमति देता है जो निर्भर परीक्षण मामलों को निर्दिष्ट करता है और आश्रित परीक्षण मामलों के बीच तर्क पारित करने की अनुमति देता है।

0
जोड़ा
QAIndia
QAIndia
160 प्रतिभागियों की

QA India ! Unite Here we share job postings , prepare for interviews and share tips/techniques in QA. Please follow following guideline while sharing any job ... QA job # location : # title Company : Title : Requirement: Responsibility: Apply: