PHPUnit을 사용한 WordPress 플러그인 자동 테스트 소개

WordPress는 시작하기 쉽고 수많은 테마와 플러그인을 사용하여 기능 세트를 확장할 수 있기 때문에 웹사이트 구축에 널리 사용되는 콘텐츠 관리 시스템입니다. WordPress에 많은 플러그인과 테마가 있는 주된 이유는 모든 수준의 개발자가 쉽게 빌드를 시작할 수 있기 때문입니다. 대부분의 개발자는 경험이 없으며 아마도 다음과 같은 이유로 작업에 대한 테스트를 작성하지 않습니다.

• 단위 테스트에 대한 논의가 많지 않기 때문에 테스트가 가능한지조차 모를 수 있습니다.
• 그들은 자신의 코드에 대한 테스트를 작성하는 것의 가치를 믿지 않거나 속도가 느려질 것이라고 생각합니다.
• 그들은 플러그인이나 테마가 브라우저에서 작동하는지 테스트하는 것으로 충분하다고 믿습니다.

이 튜토리얼에서는 자동화된 테스팅이 무엇인지와 그 중요성을 배우고, PHPUnit과 WP-CLI에 대해 알아보고, 테스트를 작성하는 방법을 배우고, 마지막으로 Travis CI를 사용하여 지속적인 자동화 테스팅을 설정합니다.

Travis CI는 GitHub와의 원활한 통합을 제공하기 때문에 사용하기로 결정했습니다. 저장소로 이동하여 이들 간의 연결을 설정할 필요가 없습니다. 그리고 공개 리포지토리의 경우 무료입니다. Semaphore CI, GitLab CI 및 CircleCI와 같은 경쟁사와 달리 Travis CI는 무료 개인 저장소 계획을 제공하지 않습니다. 그러나 경쟁사 중 어느 것도 GitHub와 원활한 통합을 제공하지 않습니다.

자동화된 테스트란 무엇입니까?

Wikipedia에 따르면 자동화된 테스트 또는 테스트 자동화는 테스트 실행 및 예상 결과와 실제 결과의 비교를 제어하기 위해 특수 소프트웨어(테스트 중인 소프트웨어와 별도로)를 사용하는 것입니다. 테스트 자동화는 이미 시행 중인 공식화된 테스트 프로세스에서 반복적이지만 필요한 일부 작업을 자동화하거나 수동으로 수행하기 어려운 추가 테스트를 수행할 수 있습니다.

여러 유형의 테스트가 있습니다. 그 중에서도 단위 테스트가 가장 인기가 있습니다. 단위 테스트는 코드 블록, 함수 또는 클래스 메서드가 의도한 대로 수행되는지 확인합니다. 이 자습서에서는 단위 테스트를 수행합니다.

자동화된 테스트는 버그를 감지하는 데 도움이 되므로 버그가 프로덕션 단계로 넘어가지 않도록 합니다. 의심할 여지 없이 코딩되고 테스트된 플러그인은 테스트되지 않은 플러그인보다 완료하는 데 시간이 더 오래 걸립니다. 그러나 결과 플러그인에는 버그가 거의 또는 전혀 포함되지 않습니다.

단위 테스트가 얼마나 소중한지, 그리고 무엇을 위해 사용할 수 있는지에 대한 간단한 실제 예를 살펴보겠습니다.

내 WordPress 리드 생성 플러그인에는 새 옵트인 양식 템플릿을 추가하기 위한 add() 메서드와 옵트인 양식 템플릿을 검색하기 위한 get() 메서드가 있는 OptinThemesRepository 클래스가 있습니다.

add() 와 get() 이 현재와 미래에 의도한 대로 작동하는지 확인하기 위해 아래 테스트를 작성했습니다.

 public function testAddGetMethods() { $kick_optin_form = array( 'name' => 'Kick', 'optin_class' => 'kick', 'optin_type' => 'kick', 'screenshot' => MAILOPTIN_ASSETS_URL . 'img/kick.png' ); // add kick optin theme OptinThemesRepository::add($kick_optin_form); $result = OptinThemesRepository::get('kick'); $this->assertEquals($kick_optin_form, $result); }

앞으로 이 테스트가 실패하기 시작하면 문제가 있다는 것을 알고 플러그인에서 문제가 발생하는 정확한 기능, 클래스 메서드 또는 지점을 알게 될 것입니다.

자동화된 테스트의 이점

이제 자동화 테스트가 무엇인지 알았으므로 더 많은 이점을 살펴보겠습니다.

조기 버그 감지

소프트웨어를 개발하는 동안 자동화된 테스트 도구를 사용하여 버그를 쉽게 찾을 수 있습니다. 이렇게 하면 버그를 추적하는 데 많은 시간과 노력을 절약할 수 있습니다.

더 높은 소프트웨어 품질

다년간의 경험을 가진 테스터가 똑같은 지루한 수동 테스트 스크립트를 반복해서 준비해야 할 때 실수를 할 수 있습니다. 자동화된 테스트는 정확한 결과를 얻을 뿐만 아니라 시간도 절약합니다.

쉽고 강력한 보고

자동화된 테스트 도구는 각각의 모든 테스트 스크립트를 추적할 수 있습니다. 각 테스트 스크립트의 실행은 시각적 로그에서 볼 수 있습니다. 시각적 로그 또는 보고서는 일반적으로 실행된 테스트 스크립트 수와 해당 상태(예: 통과, 실패 또는 건너뛰기), 보고된 버그 및 버그 수정 방법에 대한 힌트를 표시합니다.

테스트를 설정하고 작성하는 방법을 살펴보기 전에 사례 연구로 사용할 간단한 플러그인을 만들어 보겠습니다.

WordPress 플러그인 빌드

WordPress의 프런트 엔드 헤더에 Google 및 Bing 웹마스터 확인 메타 태그를 표시하는 간단한 플러그인을 빌드할 것입니다. 플러그인은 내 GitHub 계정에서 호스팅됩니다.

아래 이 플러그인의 코드는 wp-meta-verify.php 파일에 있습니다.

 <?php class WP_Meta_Verify { public function __construct() { add_action('wp_head', \[$this, 'header_code']); } public function header_code() { $google_code = get_option('wpmv_google_code'); $bing_code = get_option('wpmv_google_code'); echo $this->google_site_verification($google_code); echo $this->bing_site_verification($bing_code); } public function google_site_verification($code) { return "<meta name=\"google-site-verification\" content=\"$code\">"; } public function bing_site_verification($code) { return "<meta name=\"msvalidate.01\" content=\"$code\">"; } } new WP_Meta_Verify();

일반적으로 Google 및 Bing 인증 코드를 저장하는 설정 페이지가 플러그인에 포함되지 않았음을 알 수 있습니다. 나는 이것을 단순하게 유지하고 가장 중요한 것에 주의를 집중하기 위해 의도적으로 이 작업을 수행했습니다. 그러나 get_option('wpmv_google_code') 및 get_option('wpmv_bing_code') 은 설정 페이지가 있다고 가정하고 거기에서 인증 코드를 검색합니다.

WordPress 플러그인 단위 테스트

PHPUnit은 PHP용 사실상 의 테스트 도구인 반면 WP-CLI는 WordPress의 공식 명령줄 인터페이스입니다.

WP-CLI 이전에는 WordPress 플러그인에 대한 PHPUnit 테스트를 설정하는 것이 어려웠습니다. WP-CLI에는 설정에 대한 훌륭한 가이드가 있습니다. 그러나 여기에서 단계를 계속 진행할 것입니다.

PHPUnit 설치

PHPUnit을 설치하려면 다음 명령어를 실행하세요.

 composer global require phpunit/phpunit:5.*

참고: 내 컴퓨터에 있는 PHP 7 이상을 실행할 때 WordPress가 지원하는 것이기 때문에 명시적으로 5.x 를 설치합니다. PHP 버전 5를 실행하는 경우 PHPUnit 4.8을 설치합니다.

phpunit --version 을 실행하여 설치되었는지 확인합니다.

WP-CLI 설치

WP-CLI를 설치하려면 다음 명령을 실행하십시오.

 curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar chmod +x wp-cli.phar sudo mv wp-cli.phar /usr/local/bin/wp

wp --info 를 실행하여 설치를 확인합니다.

PHPUnit 및 WP-CLI를 설치한 후 후자를 사용하여 플러그인에 대한 단위 테스트를 설정합니다.

플러그인 단위 테스트 설정

터미널의 디렉토리를 워드프레스 설치 루트로 변경하고 아래 명령어를 실행하여 플러그인 테스트 파일을 생성합니다.

 wp scaffold plugin-tests wp-meta-verify

다음은 위의 명령으로 테스트 파일을 생성한 후의 플러그인 구조입니다.

 |-bin/ |----install-wp-tests.sh |-tests/ |----bootstrap.php |----test-sample.php |-.travis.yml |-phpcs.xml.dist |-phpunit.xml.dist |-wp-meta-verify.php

참고: 기본적으로 wp scaffold plugin-tests 명령은 Travis CI 구성 파일을 생성합니다. --ci 플래그를 지정하여 사용하는 CI 서비스에 대한 구성 파일을 생성할 수 있습니다(예: wp scaffold plugin-tests --c gitlab . 작성 당시와 같이 Travis CI, CircleCI, GitLab CI만 지원합니다.

터미널 디렉토리를 플러그인 디렉토리로 변경하고 설치 스크립트를 실행하십시오:

 cd path-to-wordpress-plugin

 bin/install-wp-tests.sh wordpress_test root '' localhost latest

나와 같다면 MySQL 사용자 이름이 root 가 아니며 암호가 비어 있지 않습니다. 예를 들어 사용자 이름이 homestead 이고 암호가 secret 이라고 가정합니다. 다음과 같이 설치 스크립트를 실행합니다.

 bin/install-wp-tests.sh wordpress_test homestead 'secret' localhost latest

phpunit 명령을 실행하여 tests/test-sample.php 에서 기본 테스트를 실행합니다.

플러그인 테스트 작성

tests 폴더에 test-wp-meta-verify.php 파일을 생성합니다. 여기에는 다음 setUp 클래스가 포함된 플러그인 테스트가 포함됩니다.

 <?php class WP_Meta_VerifyTest extends WP_UnitTestCase { public function setUp() { parent::setUp(); $this->class_instance = new WP_Meta_Verify(); } public function test_google_site_verification() { } public function test_bing_site_verification() { } }

메서드가 단위 테스트로 간주되기 위해서는 test 접두사가 있어야 한다는 점은 주목할 가치가 있습니다. 필수는 아니지만 가장 좋은 방법은 모든 테스트 클래스에 Test 접미사를 추가하는 것입니다. WP_Meta_VerifyTest 를 참조하십시오.

setUp() 이 하는 일에 대해 혼란스럽습니까? PHPUnit은 테스트 케이스 클래스의 각 테스트 메소드(그리고 새로운 인스턴스에서) 전에 한 번만 실행한다는 것을 알아두십시오. 또한 tearDown() 이 있지만 각 테스트 메서드 후에 실행됩니다. 각 테스트 케이스 전후에 각각 실행되는 setUpBeforeClass() 및 tearDownAfterClass() 도 있습니다. 테스트 케이스는 기본적으로 여러 테스트 메소드를 포함하는 클래스입니다. 자세한 내용은 워드프레스 핸드북 및 PHPUnit 문서를 참조하십시오.

위의 클래스에서 플러그인 클래스의 google_site_verification 및 bing_site_verification 메서드에 대한 테스트를 작성할 것이 분명합니다.

 public function test_google_site_verification() { $meta_tag = $this->class_instance->google_site_verification('B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g'); $expected = '<meta name="google-site-verification" content="B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g">'; $this->assertEquals($expected, $meta_tag); }

 public function test_bing_site_verification() { $meta_tag = $this->class_instance->bing_site_verification('B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g'); $expected = '<meta name="msvalidate.01" content="B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g">'; $this->assertEquals($expected, $meta_tag); }

기본적으로 테스트는 Google 및 Bing 웹마스터 인증 코드가 인수로 전달될 때 두 메서드 모두 올바른 메타 태그를 반환하는지 확인합니다.

phpunit 을 실행하면 아래 스크린샷과 유사한 출력이 표시됩니다.

Travis CI를 사용한 지속적인 자동화 테스트

Travis CI는 GitHub에서 호스팅되는 소프트웨어 프로젝트를 빌드하고 테스트하는 데 사용되는 호스팅되고 분산된 지속적 통합 서비스입니다.

따라서 Travis CI를 사용하려면 GitHub에 플러그인을 게시해야 합니다. 지금 하세요. 내 것을 참조하십시오.

WP-CLI 덕분에 .travis.yml 파일을 통해 플러그인에 이미 설정했습니다.

나는 WordPress 코딩 표준이 아니라 PHP 표준 권장 사항을 따르고 있으며 내 플러그인에는 PHP 5.4 이상이 필요합니다. 내 빌드가 실패하지 않도록 .travis.yml 파일에서 매트릭스를 다음으로 교체해야 했습니다.

 matrix: include: - php: 7.1 env: WP_VERSION=latest - php: 7.0 env: WP_VERSION=latest - php: 5.6 env: WP_VERSION=latest - php: 5.6 env: WP_VERSION=trunk - php: 5.5 env: WP_VERSION=latest - php: 5.4 env: WP_VERSION=latest

Travis CI로 이동하여 GitHub 계정으로 로그인합니다. 화면 안내에 따라 GitHub 리포지토리를 추가하세요.

GitHub와 계정 동기화 후 플러그인 저장소로 스크롤하여 활성화합니다.

다음에 코드를 변경하고 GitHub에 푸시하면 Travis CI에서 빌드가 트리거됩니다.

나는 당신이 보는 즐거움을 위해 성공적인 빌드 결과를 제공했습니다.

마무리

WordPress 개발자뿐만 아니라 많은 개발자가 프로젝트에 대해 모르기 때문에 테스트를 작성하지 않는다는 것은 비밀이 아닙니다. 우리 중 경험이 풍부하고 진보한 사람들도 시간 낭비라고 생각하기 때문에 그렇게 하지 않는 것 같습니다.

물론 자동화된 테스트를 설정하는 것은 지루하고 시간이 많이 소요될 수 있습니다. 그럼에도 불구하고 소프트웨어에 버그가 거의 또는 전혀 침투하지 않도록 하는 투자이므로 소프트웨어의 버그로 인해 비용이 드는 시간과 리소스(재정 포함)를 절약할 수 있습니다.

기능을 구현하기 전에 항상 테스트를 작성하여 기능이 구현된 후에 하는 것을 잊어버리거나 게으르다고 느끼지 않도록 하십시오.

이제 테스트 작성의 중요성과 자신의 WordPress 플러그인용 테스트 작성을 시작하는 방법을 인식하시기 바랍니다.

질문이나 의견이 있으면 의견 섹션에 알려주십시오.