회귀 테스트를위한 모범 사례 WordPress 웹 사이트?

안녕 모두

자동화 된 회귀 테스트에 사용하는 플랫폼으로 WordPress를 사용하여 복잡한 비 블로그 솔루션을 고객에게 제공하는 다른 사람들의 의견을 듣고 싶습니다 .

"회귀 테스트" 라는 용어에 익숙하지 않은 사람들을 위해 Wikipedia는이를 다음과 같이 정의합니다.

회귀 테스트는 프로그램을 다시 테스트하여 프로그램을 변경 한 후 (예 : 버그 수정 또는 새로운 기능) 소프트웨어 오류를 찾아내는 모든 유형의 소프트웨어 테스트입니다. 회귀 테스트의 목적은 버그 수정과 같은 변경으로 인해 새로운 버그가 발생하지 않았 음을 확인하는 것입니다.

더 많은 Wikipedia에 따르면 다음은 프로젝트에서 지금 겪고있는 것입니다.

경험에 따르면 소프트웨어가 수정됨에 따라 새로운 결함의 출현 및 / 또는 오래된 결함의 출현이 매우 일반적입니다. 잘못된 수정 제어 방법 (또는 수정본 제어의 간단한 인적 오류)을 통해 수정 사항이 유실되어 재발이 발생할 수 있습니다. 종종 문제에 대한 수정은 문제가 처음 발견 된 좁은 경우에 문제를 해결하지만 소프트웨어의 수명 기간 동안 발생할 수있는보다 일반적인 경우에는 문제가되지 않기 때문에 "깨지기 쉽습니다". 한 영역의 문제에 대한 수정으로 인해 다른 영역의 소프트웨어 버그가 실수로 발생하는 경우가 종종 있습니다. 마지막으로, 일부 기능이 재 설계 될 때, 해당 기능의 원래 구현에서 이루어진 동일한 실수가 재 설계에서 발생하는 경우가 종종 있습니다.

작업 및 필터의 글로벌 특성으로 인해 클라이언트가 요청한 기능을 더 추가할수록 복잡성이 증가하기 시작하고 특히 복잡한 호출을 많이 사용 WP_Query하고 데이터베이스를 많이 업데이트하는 경우 복잡한 플러그인을 안정적으로 얻는 것이 어려워집니다. .

내 마음에 솔루션은 일련의 "테스트 사례" 를 사용하여 회귀 테스트를 설정 하여 "테스트 스위트 " 를 구성하는 것 입니다. 개념적으로 HTTP GET 요청의 HTML 출력을 테스트 할 때 그리 어렵지 않습니다. 그러나 관리 콘솔을 통해 로그인하거나 jQuery 상호 작용을 테스트해야 할 때 테스트해야 할 때 조금 더 복잡해집니다.

나는 우리가 여기에서 모범 사례를 수집 할 수 있기를 희망하면서 이것을 커뮤니티 위키로 설정하고 있지만 다른 WordPress 전문가가 사용하고 있다면 프로세스를 듣는 것이 정말로 불안합니다.

WP 테스트 스위트가 그렇게 망가지지 않았고 WP가 실제로 올바르게 테스트 될 수있는 방식으로 설계되고 작성 되었다면 PHPUnit은 떠 올랐습니다. ;-)

더 진지하게, 단위 테스트 등으로 기능적 관점에서 원하는 모든 플러그인을 테스트 할 수 있습니다. 문제는 이러한 테스트를 통해 WP 업그레이드로 인한 미묘한 기회를 잡을 수 있다고 보장 할 수는 없지만 맞춤형 WP 설치에 연결 한 후에도 계속 작동한다는 것입니다.

내가 본 화려한 것들 중 :

• WP API의 미묘한 변화는 플러그인의 기능에 영향을 미칩니다. 예를 들어 용어 ID를 얻는 데 사용되는 후크는 이제 용어 분류 ID를 가져옵니다. 테스트 조건이 두 가지 모두에 대해 동일한 ID를 갖도록하는 것이 좋습니다.

• WP API가 미묘하게 변경 WP_Error되면 이전에 예상했던 false잘못된 입력 값 대신 객체를 수신하게 됩니다 .

• mu-plugins 폴더 내에서 플러그인이 추가되어 코드 흐름이 미묘하게 달라집니다.

• memcached 또는 다른 영구 저장소가 활성화 될 때까지 플러그인이 제대로 작동했습니다.

• 멸시 된 switch_to_blog ()가 호출 될 때까지 플러그인이 제대로 작동했습니다.

• 플러그인은 호출 될 때 상주하는 후크를 변경하고 모르게 부작용으로 중단합니다.

• 플러그인 (un?)은 입력 또는 출력 데이터를 실수로 잘못해도 문제가 발생하는 지점까지 혼란스럽게 만듭니다.

나는 목록을 계속해서 확장 할 수 있지만 그것들은 내 플러그인을 깨뜨린 주요 아이템 일 것이다. 두 가지 항목은 모두 단위 테스트로 잡을 수 있습니다. 다음 두 가지도 충분히 인내심이 있지만 WP가 일이 일어날 때 작동 방식을 바꾸지 말아야한다고 주장합니다. switch_to_blog ()의 버그가있는 구현에 대해서는 많은 테스트가 수행되지 않습니다. 그리고 마지막 두 사람은 절망적으로 테스트 할 수 없습니다.

아, 그리고 ... 첨부 파일, 자동 초안, 개정판, 메뉴 항목 및 그 결과가 포스트 테이블에 저장되지 않은 것부터 시작하지도 않습니다.

행운을 빕니다... :-)

Selenium을 강력하게 고려해야 합니다.

작업을 기록 (예 : 양식에 데이터 입력, 링크 클릭) 한 다음 어설 션을 수행 할 수 있습니다. 또한 PHPUnit과 통합됩니다. 2 분 데모를 확인하는 것이 좋습니다.

셀레늄은 아마도 사용 가능하지만 현대에는 Codeception 이 더 좋고 사용하기 쉽다고 생각합니다. 가장 간단한 시각적 회귀 테스트 를 위해 스크린 샷을 찍고 자동으로 비교 하는 확장 기능 도 있습니다.

물론 Codeception WebDriver 테스트는 더 나아가 기능 회귀 테스트를 수행 할 수 있습니다 . 양식을 작성하여 제출하고, 사이트에서 버튼과 링크를 클릭하고, JS 등을 실행할 수 있습니다. 테스트에서 Firefox 또는 Chrome과 같은 실제 브라우저를 사용하거나 PhantomJS로 헤드리스 테스트를 수행 할 수 있습니다 . 즉, 원하는 경우 Travis CI에서 빌드 프로세스의 일부로 플러그인에 대한 WebDriver 테스트를 실행할 수도 있습니다 .

시작하는 데 도움이되는 몇 가지 WordPress 관련 라이브러리도 있습니다.

• WP 브라우저
• WP Codeception