Robert는 Drupal의 SimpleTest를 사용한 단위 테스트에 대한 훌륭한 기술 게시물을 여기 에 썼습니다 . 워크 플로 및 구성 부분을 다루는 데 더 관심이 있습니다. 현재 개발 머신, 스테이징 및 프로덕션 서버가 있습니다. 프로덕션 사이트와 스테이지 사이트는 모두 300MB RAM / 300MHz CPU Dreamhost VPS에서 실행됩니다.
답변:
루비 세계에서 TDD는 프레임 워크에 내장 된 도구로 촉진됩니다. Factory Girl, Mocha, rSpec 등을 통해 개발자는 필요한 테스트 사례를 해결하는 쉽고 역동적 인 테스트를 만들 수 있습니다.
Drupal의 TDD 도구가 부족하여 좌절했습니다. 그들과의 가장 큰 문제는 단일 테스트를 실행하는 데 걸리는 시간입니다. 각 반복마다 60-90 초가 걸리는 개별 테스트로 개발주기를 늦출 수 없습니다. 테스트를 전혀 작성하지 않으려면 전체 테스트 스위트가 여러 시간 동안 실행됩니다.
테스트가 실행될 때마다 전체 DB를 복사하는 것과 관련이 있다고 생각하지만, DrupalWebTestCase를 사용해야하는 경우 가까운 미래에 내가 말할 수있는 것에서 변경되지는 않습니다.
Drupal을 수동으로 부트 스트랩 하는 Phactory 와 phpunit을 사용하여 솔루션을 해킹 하고 있습니다. 분명히 몇 가지 문제가 발생하여 끝내지 못했지만 아직 끝나고 있습니다.
다행히도 대부분의 작업은 백엔드 레이어에 있으므로 DRUPAL_BOOTSTRAP_DATABASE 수준을 유지할 수 있습니다. 그러나 전체 스택이 필요한 더 많은 상황에 처해 있습니다.
결국 Drupal의 TDD는 잘 지원되지 않으므로 Drupal 테스트 프레임 워크 외부에서 작동하도록 자체 작성하거나 성능 저하를 견딜 수 있습니다.
-업데이트-
Drupal과 Phactory의 완전한 통합을 성공적으로 설정했으며 이제 Drupal Web Test Case 대신 phpunit을 통해 테스트를 실행하고 있습니다. 가능합니다.
나는 그것을 릴리스 할 수 있고 Phactory doc에 통합 될 수있는 시점에 도달하기를 바랍니다.
-업데이트 2-
Phactory 설정 방법에 대한 문서는 https://github.com/trimbletodd/phactory에 있습니다.
Mark의 블로그가 오프라인 상태이므로 팀에서 구현 한 도구 중 일부에 대해 언급하겠습니다.
기능 테스트 : Selenium
단위 테스트 : Simpletest
빌드 서버 : Jenkins
성능 벤치마킹 : XDebug + Cachegrind
이 질문을한지 2 년 만에 일부 추가 도구가 TDD 장면에서 인기를 얻는 것을 보았습니다. 오늘날 드루팔 (Drupal) 환경에서 Test Driven Development에 관해 이야기 할 때, 같은 코인에는 프론트 엔드 테스트와 백엔드 테스트라는 두 가지 측면이 있습니다.
이 문제를 나타내는 최신 Drupalcon Portland 2013에서 눈에 띄는 두 가지 프레젠테이션이 있습니다.
백엔드 테스트에 의한 개발 .
Jasmine 및 PhantomJS를 사용한 자동화 된 테스트 , 프론트 엔드 테스트.
첫 번째 프레젠테이션은 단위 또는 기능 테스트 (엄격히 말해서)와 관련이 없으며 코드 품질을 측정하는 도구에 대한 것입니다. 그럼에도 불구하고 주제와 관련이 있다고 생각합니다.
내가 아는 유일한 것은 기여 모듈의 경우 이슈 큐에서 커밋 및 패치 의 자동 테스트를 활성화 할 수 있다는 것입니다 ( http://drupal.org/node/689990 참조) . 특히 의존성이있는 경우 여전히 불안정합니다.
대부분의 프로젝트는 버그 중심 개발 라인을 따라 더 많은 작업을 수행 할 것입니다. 기본적으로 버그가 발견되면 테스트를 작성한 다음 수정합니다. 전혀 그렇지 않으면;)
개인적인 경험으로 볼 때, TDD는 Drupal에서 다소 어려움을 겪습니다. 단순 테스트로 단위 테스트를 작성하지 않고 페이지를보고 양식을 제출하는 통합 테스트를 작성하기 때문입니다. 따라서 좋은 테스트를 미리 작성하기는 다소 어려울 수 있습니다. 하지만 어쩌면 나는 그렇게하는 데 익숙하지 않습니다 :)