Pest PHP 테스트 프레임워크로 WordPress 코드 테스트를 시작하는 방법

게시 됨: 2022-05-18

우리 모두는 WordPress가 시작부터 먼 길을 왔고 블로깅 소프트웨어 이상의 무언가로 성장했다는 데 동의할 수 있습니다.

핵심은 여전히 ​​콘텐츠 관리 시스템(CMS)이지만 wordpress.org 디렉토리에 59,000개 이상의 플러그인이 있으므로 훨씬 더 많이 사용자 정의할 수 있습니다.

인기의 이유는 콘텐츠 제작자와 개발자 모두의 진입 장벽이 낮기 때문입니다. 때때로 이것은 비용을 수반합니다. WordPress가 개발과 관련하여 나쁜 평판을 받고 있다는 것은 비밀이 아닙니다. PHP 코드와 관련하여 이전 버전과의 호환성을 깨는 변경을 방지하는 많은 레거시 수하물과 엄격한 규칙이 있습니다(Gutenberg는 제가 다루지 않을 또 다른 이야기입니다).

그 레거시 PHP 코드는 프로그래밍 세계에 입문하기 시작한 개발자가 자주 사용하며 문제는 일부 잘못된 프로그래밍 패턴을 배울 수 있다는 것입니다. 이는 차례로 그들이 잘못 작성된 코드를 재사용하여 세상에 나쁜 코드의 양을 증가시킨다는 것을 의미합니다.

이것이 WordPress가 개발자 커뮤니티에서 나쁜 평판을 얻는 곳입니다.

사이클을 깨다

그렇다면 이 나쁜 코드의 순환을 어떻게 끊을 수 있습니까? 새로운 개발자에게 좋은 코드를 작성하는 방법을 가르칩니다. 새로운 개발자(그러나 여전히 'WordPress' 방식에 집착하는 오래된 개발자)를 가르치는 한 가지 예는 자습서를 작성하는 것입니다.

또 다른 방법은 더 나은 코드를 작성하는 데 도움이 되는 도구를 사용하도록 권장하는 것입니다.

저는 현재 코드에 잠재적인 문제(보안, 모범 사례, 코드 스타일)가 있는지 알려주는 PHP_CodeSniffer 도구에 사용되는 일련의 규칙인 WordPress 코딩 표준의 새 버전을 출시하는 것을 목표로 하는 작업에 참여하고 있습니다. ).

내가 최근에 개발한 또 다른 도구는 개발자가 Pest 테스트 프레임워크를 사용하는 WordPress 통합 테스트를 설정하는 데 도움이 되는 패키지입니다.

자, 왜 이 새로운 도구가 필요한가요?

이 패키지를 만드는 주된 동기는 더 많은 사람들, 특히 플러그인 개발자가 자신의 코드에 대한 테스트를 작성하도록 장려하는 것입니다.

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의 장점은 구문이 개발자 친화적이라는 것입니다. 놀라운 문서와 훌륭한 구문이 있습니다. 간단한 예를 살펴보겠습니다. 'Books'라는 사용자 정의 게시물 유형을 등록한다고 가정해 보겠습니다.

 <?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와 통신하는 플러그인의 경우 특히 그렇습니다.

이러한 코드베이스에 대한 테스트를 작성하면 모든 것을 수동으로 테스트할 필요가 없어 시간과 비용을 절약할 수 있을 뿐만 아니라 자동화된 테스트를 쉽게 작성할 수 있도록 코드 아키텍처가 어떻게 생겼는지 생각해야 합니다.

이것이 도움이 될 수 있다고 생각되면 자유롭게 사용하고 GitHub의 리포지토리에 별표를 표시하십시오.

바라건대 이것은 더 많은 WordPress 개발자가 코딩 기술을 향상시킬 도구를 사용하도록 장려할 것입니다.