언어 간 테스트 주도 개발

9

짧은 질문 : 여러 언어로 된 프로젝트에서 어떻게 테스트 주도 개발을 수행합니까?

특히 JavaScript와 PHP를 사용하는 웹 응용 프로그램을 작성하고 있으며 TDD 원칙을 따르고 싶지만 어떻게 통합해야하는지 잘 모르겠습니다. JS 및 PHP 섹션에 대해 별도의 테스트 스위트를 실행하고 JS 스위트에서 모의를 사용하여 서버 응답을 에뮬레이트합니까? 한 번의 실행으로 두 구성 요소를 모두 단위로 테스트하는 기술이 있습니까?

이것은 테스트 주도 개발을 사용한 나의 첫 경험이므로, 덜 힘들게 만드는 방법에 대해 공유 할 수있는 조언은 훌륭 할 것입니다. 제가 선택한 이유는 프로토 타입을 완성하자마자 요구 사항이 변경되어 디자인을 변경해야했기 때문입니다. 다시 시작하면 처음부터 내장 회귀 테스트를 통해 더 확장 가능한 코드를 작성하고 싶습니다.

SimpleTest에서 PHP 테스트를 작성하고 JsTestDriver에서 JavaScript 테스트를 작성하고 있습니다. 객체 지향 패러다임에 익숙 했으므로 PHP로 몇 가지 클래스를 얻었으며 프로토 타입 상속을 사용하여 JavaScript에서 비슷한 작업을 수행하고 있습니다. 또한 읽기 시작했습니다 파이썬에서 TDD에 대한이 책 과 자바 스크립트 TDD에 대한이 일을 하지만, 내가 본 것을 모두에서, 이들은 셀레늄 또는 다른 웹 드라이버 같은 것을 사용하는 (전체에서 외부 응용 프로그램을 테스트 설명하지 않습니다 TDD는 풀 스택 개발자를 위해 잘리지 않습니까?

— 크리스 올슨
소스

1

SimpleTest를 사용하지 않으면 PHPUnit으로 전환하는 것이 좋습니다. SimpleTest는 조롱 및 코드 적용과 관련하여 매우 활동적이지 않고 약간 뒤쳐집니다.

— Cerad

9

한 번의 실행으로 두 구성 요소를 모두 단위로 테스트하는 기술이 있습니까?

실제로 TDD 스타일에서 단위 테스트 단위 테스트 와 반대되는 것은 구성 요소를 개별적 으로 테스트하는 것을 의미합니다 . 따라서 "JS 및 PHP 섹션에 대해 별도의 테스트 스위트를 실행하십시오" 라는 대답이 그렇습니다. 그렇지 않으면 단위 테스트가 아니라 TDD가 아닙니다.

물론, 자동화 된 통합 테스트는 "한 번의 실행으로 두 구성 요소 모두"를 테스트 할 수 있으며 이미 언급 한 도구 (예 : Selenium)를 정확하게 활용할 수 있습니다. 그러나 이러한 테스트는 일반적으로 TDD주기 외부에서 개발 된보다 복잡한 테스트입니다.

— 닥 브라운
소스

3

중요한 것은 TDD와 ATDD 를 구별하는 것입니다 . AT는 " 수락 테스트"를 의미하며, 이는 전체 스택을 테스트 할 수있는 수락 테스트로 시작하는 개발을 나타냅니다. 이것을 "외부 테스트 주도 개발"이라고도합니다. 사람들이 TDD에 대해 이야기 할 때 "T"는 아마도 단위 테스트 를 의미 합니다.

단위 테스트의 주요 부분은 테스트 대상 단위를 종속 항목에서 분리하는 것입니다. 이것은 두 가지 중요한 이점을 제공합니다.

테스트를 매우 빠르게 수행 할 수 있으므로 매우 짧은 피드백주기의 일부로 테스트를 자주 실행할 수 있습니다. 매 시간마다 실행하는 대신 작은 변화가있을 때마다 모든 단위 테스트를 실행할 수 있어야합니다. 따라서 변경 사항이 발생했는지 여부에 대한 피드백을 즉시 얻을 수 있습니다.
테스트는 한 번에 매우 특정한 행동을 목표로 할 수 있습니다. 그 중 하나가 실패하면 테스트에서 나타내는 버그의 정확한 특성을 거의 즉시 확인할 수 있어야합니다.

이러한 격리의 중요성으로 인해 언어 경계보다 훨씬 작은 단위로 테스트를 자동으로 제한하기를 원합니다. 어렵고 빠른 규칙은 아니지만 단일 클래스가 테스트 가능한 단위가되는 경우가 종종 있습니다. 따라서 TDD 측면에서 언어 문제는 다소 관련이 없습니다.

다른 한편으로, ATDD를하고자한다면,이를위한 자원을 구체적으로 살펴보십시오 (BDD의 일부로 수행되는 경우도 있으므로 해당 도구를 살펴보십시오). 여기 Selenium과 같은 것이 자연스럽게 들어 맞는 곳이 있습니다. 일반적으로 ATDD를 수행 할 때 여전히 단위 테스트를 작성합니다. 실제로 각 합격 테스트를 통과하기 위해 단위 테스트로 구현을 테스트 할 수도 있습니다. 따라서 ATDD를 원하더라도 단위 테스트 작성 방법을 이해하는 것이 여전히 중요합니다.

— 벤 애런 슨
소스

쿨, 나는 ATDD를 보지 못했지만 BDD에 대한 Behat과 Behave에 익숙하다. 의견을 보내 주셔서 감사합니다. 아직도 TDD의 미세한 테스트 정신으로 내 머리를 감싸려고 노력하고 있습니다 :)

— Chris Olsen

@ChrisOlsen 두 가지 측면이 있습니다. 단위 테스트 (통합 또는 승인과 비교)와 작성 시점 (후가 아니라 프로덕션 코드 이전)입니다. 둘 다 이상한 사고처럼 보인다면 두 번째 이전의 첫 번째 주제를 파악하려고 시도 할 수 있습니다. 많은 사람들이 TDD를 연습하지는 않지만 여전히 철저한 단위 테스트 범위를 주장합니다.

— Ben Aaronson

1

또한 응용 프로그램의 전체 스택에 TDD를 사용할 필요가 없습니다. 개발 방법론 인 TDD는 응용 프로그램의 논리 부분에 더 적합합니다. 프런트 엔드 디자인, 특정 상호 작용 또는 데이터베이스 도메인 디자인과 같이 실험적인 부분이 필요한 부분은 최종 버전이 될지 아직 알지 못하므로 전통적인 스타일로 더 잘 수행됩니다.

그러나 응용 프로그램의 논리는 미래에 변경되지 않아야하며, 그렇게된다면 훨씬 까다로운 요구 사항에 직면하게됩니다. 따라서 TDD의 궁극적 인 목표 인 코드를 변경할 때마다 일련의 회귀 테스트에 대한 자신감을 가질 수 있습니다.

Bob 아저씨는이 방법을 나보다 잘 설명합니다. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html

— 클라 마치
소스