WordPress의 맞춤 게시 유형 권한을 PHPUnit으로 테스트
14677 단어 PHPUnitWordPressWP_UnitTestCase
그 때 그것이 제대로 의도 한대로 작동하는지 확인하고 싶지만 사용자를 만들고 여러 번 로그인하거나 로그 아웃하는 것은 귀찮게 수정을 반복하는 동안 수상한 일입니다. 오는 경우도 있으므로, 이 확인 작업은 어쨌든 자동화해야 합니다.
맞춤 게시물 유형 만들기
이번에는 아래와 같은 느낌으로 커스텀 투고 타입을 만들었습니다.
register_post_type( 'log', array(
'labels' => array(
'name' => "Logs",
),
'public' => false,
'show_ui' => true,
'menu_icon' => 'dashicons-list-view',
'show_in_rest' => false,
'rest_base' => 'log',
'rest_controller_class' => 'WP_REST_Posts_Controller',
'capability_type' => 'page',
'capabilities' => array(
'create_posts' => 'do_not_allow',
'delete_posts' => 'do_not_allow',
),
'map_meta_cap' => false,
) );
위의 예에서 이번 중요한 것은 다음 부분입니다.
'capability_type' => 'page',
'capabilities' => array(
'create_posts' => 'do_not_allow',
'delete_posts' => 'do_not_allow',
),
'map_meta_cap' => false,
이번에 하고 싶은 것은
log
라는 커스텀 포스트 타입을 만든다. 이 유스 케이스에서는 실제의 기사는 자동적으로 퍼져 나가는 것을 상정하고 있어, 그것을 관리 화면의 표에서 볼 수 있는 것만으로 좋다고 하는 느낌입니다.
관리 화면의 표라고 하는 것은 이하와 같이 자주(잘) 보는 녀석입니다.
요점은 이것 이외는 누구에게도 보여주고 싶지 않고, 이 표를 볼 수 있는 것도
administrator
와 editor
에만 한정하고 싶다는 것입니다.이 예에서는
administrator
하지만 편집 화면에 가면 다음과 같이 됩니다.map_meta_cap
의 값을 true
로 설정하면 편집 화면이 표시됩니다.PHPUnit으로 확인
이것을 실제로 유닛 테스트로 확인하려면 다음과 같은 느낌입니다.
<?php
class Posttype_Test extends WP_UnitTestCase
{
public function test_log_post_type_should_exist()
{
$this->assertTrue( in_array( 'log', get_post_types() ) );
}
public function test_log_capabilities()
{
$post_type_object = get_post_type_object( 'log' );
$this->set_current_user( 'administrator' );
$this->assertTrue( current_user_can( $post_type_object->cap->edit_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->create_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->delete_posts ) );
$this->set_current_user( 'editor' );
$this->assertTrue( current_user_can( $post_type_object->cap->edit_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->create_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->delete_posts ) );
$this->set_current_user( 'author' );
$this->assertTrue( ! current_user_can( $post_type_object->cap->edit_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->create_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->delete_posts ) );
$this->set_current_user( 'contributor' );
$this->assertTrue( ! current_user_can( $post_type_object->cap->edit_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->create_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->delete_posts ) );
$this->set_current_user( 'subscriber' );
$this->assertTrue( ! current_user_can( $post_type_object->cap->edit_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->create_posts ) );
$this->assertTrue( ! current_user_can( $post_type_object->cap->delete_posts ) );
}
/**
* Add user and set the user as current user.
*
* @param string $role administrator, editor, author, contributor ...
* @return none
*/
private function set_current_user( $role )
{
$user = $this->factory()->user->create_and_get( array(
'role' => $role,
) );
/*
* Set $user as the current user
*/
wp_set_current_user( $user->ID, $user->user_login );
}
}
먼저 첫 번째 함수에서 원하는 맞춤 게시 유형이 존재하는지 확인합니다.
WP-CLI 로 생성한 유닛 테스트용 환경이면, 그 플러그인이
bootstrap.php
로 유효화되고 있으므로, 이 파일을 tests
디렉토리 바로 아래에 있어서 phpunit
두 번째 함수는 WordPress의 각 역할에 대해 의도한 대로 권한이 할당되었는지 확인합니다.
!
가 붙어 있는 녀석은, 그 권한이 없을 것이라는 것을 확인하고 있습니다.덜컹 거리고 모두를 일부러 쓰고 있는 것은 매번 하나 하나 조사하는 것이 귀찮기 때문에 이것을 복사하여
!
를 붙이거나 지우기 때문입니다.2번째 함수로 사용하고 있다. 입니다.
Reference
이 문제에 관하여(WordPress의 맞춤 게시 유형 권한을 PHPUnit으로 테스트), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/miya0001/items/f0104e548f491bae5432텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)