วิธีเริ่มทดสอบโค้ด WordPress ของคุณด้วย Pest PHP Testing Framework

เราทุกคนต่างเห็นพ้องต้องกันว่า WordPress มาไกลตั้งแต่เริ่มต้น และเติบโตเป็นบางสิ่งที่มากกว่าซอฟต์แวร์บล็อก

แก่นแท้ของมัน ยังคงเป็นระบบจัดการเนื้อหา (CMS) แต่ด้วยปลั๊กอินกว่า 59,000 ตัวในไดเรกทอรี wordpress.org คุณสามารถปรับแต่งให้มีอะไรอีกมากมาย

เหตุผลของความนิยมคืออุปสรรคในการเข้าสู่ต่ำสำหรับทั้งผู้สร้างเนื้อหาและนักพัฒนา บางครั้งสิ่งนี้มาพร้อมกับต้นทุน ไม่เป็นความลับที่ WordPress มีชื่อเสียงในด้านการพัฒนา มีสัมภาระแบบเดิมและกฎตายตัวมากมายที่ป้องกันไม่ให้เกิดการเปลี่ยนแปลงที่ทำลายความเข้ากันได้แบบย้อนหลังเมื่อพูดถึงโค้ด PHP (Gutenberg เป็นอีกเรื่องหนึ่งที่ฉันจะไม่เข้าไปเกี่ยวข้อง)

โค้ด PHP แบบเก่านั้นมักถูกใช้โดยนักพัฒนาที่เริ่มเข้าสู่โลกแห่งการเขียนโปรแกรม และปัญหาก็คือพวกเขาสามารถเรียนรู้รูปแบบการเขียนโปรแกรมที่ไม่ดีได้ ในทางกลับกันหมายความว่าพวกเขาจะนำโค้ดที่เขียนไม่ดีกลับมาใช้ใหม่ ซึ่งจะทำให้โค้ดที่เสียหายมีจำนวนเพิ่มมากขึ้นในโลก

นี่คือจุดที่ WordPress ได้รับชื่อเสียงที่ไม่ดีในชุมชนนักพัฒนา

หมดวงจร

แล้วเราจะทำลายวงจรของโค้ดเสียนี้ได้อย่างไร? โดยการสอนนักพัฒนามือใหม่ว่าพวกเขาควรเขียนโค้ดที่ดีอย่างไร ตัวอย่างหนึ่งของการสอนนักพัฒนามือใหม่ (แต่รวมถึงคนเก่าที่ยังคงยึดติดกับวิธีการทำ 'WordPress') คือการเขียนบทช่วยสอน

อีกวิธีหนึ่งคือการกระตุ้นให้พวกเขาใช้เครื่องมือที่สามารถช่วยให้เขียนโค้ดได้ดีขึ้น

ขณะนี้ฉันกำลังมีส่วนร่วมในงานซึ่งมีจุดมุ่งหมายเพื่อเผยแพร่เวอร์ชันใหม่ของ WordPress Coding Standards ซึ่งเป็นชุดของกฎที่ใช้สำหรับเครื่องมือ PHP_CodeSniffer ซึ่งจะแจ้งให้คุณทราบว่าโค้ดของคุณมีปัญหาที่อาจเกิดขึ้นหรือไม่ (ความปลอดภัย แนวทางปฏิบัติที่ดีที่สุด สไตล์โค้ด ).

เครื่องมืออื่นที่ฉันเพิ่งพัฒนาคือแพ็คเกจที่จะช่วยให้นักพัฒนาตั้งค่าการทดสอบการรวม WordPress ที่ใช้เฟรมเวิร์กการทดสอบ Pest

ตกลง เหตุใดเราจึงต้องการเครื่องมือใหม่นี้

แรงจูงใจหลักที่อยู่เบื้องหลังการสร้างแพ็คเกจนี้คือการสนับสนุนให้ผู้คนจำนวนมากขึ้นเขียนการทดสอบโค้ดของตน โดยเฉพาะอย่างยิ่งนักพัฒนาปลั๊กอิน

นักพัฒนาซอฟต์แวร์จำนวนมากในชุมชน WordPress ใช้มนต์นี้: ฉันเห็นว่ามันใช้ได้ผลเพราะฉันได้ลองใช้มันในเบราว์เซอร์ของฉันแล้ว ไม่เป็นไร แต่มีปัญหากับเรื่องนั้น

ประการแรก ใช้เวลานาน ทุกครั้งที่คุณทำการเปลี่ยนแปลง คุณต้องแน่ใจว่ามันใช้ได้ผล แต่ก็ไม่ได้ทำให้อะไรเสียหายด้วย

ประการที่สอง คนทำผิด เราไม่สามารถเข้าใจผิดได้ และโค้ดอาจถูกนำไปใช้ในทางที่ผิดในแบบที่คุณไม่เคยคิดว่าจะเป็นไปได้ คุณจะทึ่งในความคิดสร้างสรรค์ของคนในการเขียนโค้ด

การทดสอบอัตโนมัตินั้นรวดเร็วและสามารถช่วยคุณในการทดสอบกรณีต่างๆ ที่จะเกิดขึ้นเมื่อคุณรันโค้ดของคุณ

คุณทดสอบพฤติกรรมที่ตั้งใจไว้ (เส้นทางแห่งความสุข) และในวิธีที่รวดเร็ว คุณสามารถเพิ่มตัวอย่างวิธีการใช้โค้ดของคุณในแบบที่คุณไม่ได้ตั้งใจจะใช้ (เส้นทางที่ไม่มีความสุข)

นอกจากนี้ยังป้องกันรหัสของคุณจากการถดถอย การถดถอยของรหัสคือเมื่อคุณทำลายส่วนหนึ่งของรหัสโดยไม่ได้ตั้งใจโดยการเพิ่มรหัสใหม่

ปัญหากับการทดสอบที่ตั้งขึ้นจนถึงขณะนี้

การทดสอบใน WordPress ไม่ใช่เรื่องใหม่ และไม่ใช่ว่าคุณไม่สามารถตั้งค่าการทดสอบโค้ดของคุณได้มาก่อน มีไลบรารี่ที่น่าทึ่งมากมายที่จะช่วยคุณตั้งค่าทุกอย่างเช่น wp-browser

แต่ปัญหาคือขั้นตอนการตั้งค่ามักจะไม่เป็นระเบียบ

คุณต้องตั้งค่าฐานข้อมูลแยกต่างหากสำหรับการทดสอบ และคุณต้องเรียกใช้สคริปต์บางตัว จากนั้นเปลี่ยนไฟล์เพื่อให้ทำงานได้ทั้งหมด

มาเผชิญหน้ากัน ไม่ใช่เรื่องตรงไปตรงมาที่จะทำ และนักพัฒนาโดยธรรมชาติแล้วเป็นสิ่งมีชีวิตที่ขี้เกียจ (นั่นคือสาเหตุที่เราเขียนโค้ดเพื่อทำสิ่งต่างๆ ให้กับเรา)

จุดมุ่งหมายของการตั้งค่าการทดสอบการรวม wp-pest คือการกำจัดงานพิเศษทั้งหมด

วิธีการตั้งค่า

ในการตั้งค่า โปรเจ็กต์ของคุณต้องใช้ Composer เป็นวิธีมาตรฐานในการเพิ่มแพ็คเกจลงในโค้ดของคุณโดยพฤตินัย

ในเทอร์มินัลของคุณประเภท

 composer require dingo-d/wp-pest-integration-test-setup --dev

หลังจากที่คุณดาวน์โหลดแพ็คเกจและการอ้างอิง คุณสามารถตั้งค่าการทดสอบธีมโดยพิมพ์

 vendor/bin/wp-pest setup theme

หรือในกรณีที่คุณต้องการตั้งค่าการทดสอบปลั๊กอิน คุณสามารถเขียน

 vendor/bin/wp-pest setup plugin --plugin-slug=your-plugin-slug

คุณสามารถระบุพารามิเตอร์ --wp-version เพื่อระบุเวอร์ชัน WordPress ที่คุณต้องการทดสอบโค้ดของคุณได้

ในเบื้องหลัง อินสแตนซ์ WordPress จะถูกดาวน์โหลด และฐานข้อมูลในหน่วยความจำจะถูกตั้งค่า พร้อมด้วยตัวอย่างการทดสอบสองตัวอย่างที่คุณสามารถเรียกใช้ได้

แล้วก็วิ่ง

 vendor/bin/pest --group=unit

หรือ

 vendor/bin/pest --group=integration

จะทำการทดสอบ

ความสวยงามของ Pest คือรูปแบบที่เป็นมิตรกับนักพัฒนา มีเอกสารประกอบที่น่าทึ่งและไวยากรณ์ที่ยอดเยี่ยม ลองดูตัวอย่างง่ายๆ สมมติว่าคุณกำลังลงทะเบียนประเภทโพสต์แบบกำหนดเองที่เรียกว่า 'หนังสือ':

 <?php /** * Plugin Name: Test plugin * Desctiption: Test plugin * Version: 1.0.0 * License: MIT */ function test_plugin_register_books_cpt() { $args = array( 'label' => esc_html__( 'Books', 'test-plugin' ), 'public' => true, 'publicly_queryable' => true, 'show_ui' => true, 'show_in_menu' => true, 'query_var' => true, 'rewrite' => array( 'slug' => 'book' ), 'capability_type' => 'post', 'has_archive' => true, 'hierarchical' => false, 'menu_position' => null, 'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ), ); register_post_type( 'book', $args ); } add_action( 'init', 'test_plugin_register_books_cpt' );

หลังจากรันคำสั่งการตั้งค่าที่เพิ่มตัวอย่าง การทดสอบชื่อ BooksCptTest.php จะมีลักษณะดังนี้:

 <?php namespace Tests\Integration; beforeEach(function () { parent::setUp(); }); afterEach(function () { parent::tearDown(); }); test('Books custom post type is registered', function () { // We can use assertions from PHP_Unit. $this->assertNotFalse(has_action('init', 'test_plugin_register_books_cpt')); $registeredPostTypes = \get_post_types(); // Or we can use expectations API from Pest. expect($registeredPostTypes) ->toBeArray() ->toHaveKey('book'); });

การเรียกใช้ vendor/bin/pest --group=integration ให้ผลลัพธ์ต่อไปนี้แก่เรา:

 Installing... Running as single site... To run multisite, use -c tests/phpunit/multisite.xml Not running ajax tests. To execute these, use --group ajax. Not running ms-files tests. To execute these, use --group ms-files. Not running external-http tests. To execute these, use --group external-http. PASS Tests\\Integration\\BooksCptTest ✓ Books custom post type is registered Tests: 1 passed Time: 0.14s

บทสรุป

และเช่นเดียวกัน คุณมีความสามารถในการเรียกใช้การทดสอบการรวม WordPress ในธีมหรือปลั๊กอินของคุณ การทดสอบนั้นยอดเยี่ยมมากเพราะไม่เพียงแต่จะปกป้องเราจากความผิดพลาดเท่านั้น แต่ยังบังคับให้เราเขียนโค้ดที่สะอาดและทดสอบได้ โดยเฉพาะอย่างยิ่งสำหรับปลั๊กอินที่มีตรรกะที่ซับซ้อนหรือกำลังสื่อสารกับ API ของบุคคลที่สาม

การเขียนการทดสอบสำหรับ codebase ดังกล่าวจะบังคับให้คุณต้องคิดว่าสถาปัตยกรรมโค้ดของคุณมีหน้าตาเป็นอย่างไร คุณจึงเขียนการทดสอบอัตโนมัติได้อย่างง่ายดาย ไม่ต้องพูดถึงเวลาและเงินที่คุณจะประหยัดได้จากการไม่ต้องทดสอบทุกอย่างด้วยตนเอง

หากคุณคิดว่านี่คือสิ่งที่คุณอาจได้รับประโยชน์ โปรดอย่าลังเลที่จะใช้และติดดาวที่เก็บบน GitHub

หวังว่าสิ่งนี้จะสนับสนุนให้นักพัฒนา WordPress จำนวนมากขึ้นใช้เครื่องมือที่จะพัฒนาทักษะการเขียนโค้ดของพวกเขา