TDD와 BDD는 모두 혼동 스럽습니다. TDD와 BDD는 각각 다음 점에서 어떻게 다릅니 까?TDD VS BDD : REST 서비스
RestService 다음 (HTTP) : 나머지 통화를 할 수 없습니까? 그렇다면
a) 모의 객체를 사용하여 하드 코드 된 json 만 반환합니까?
b) REST 호출 실패를 처리하는 방법은 무엇입니까? 테스트 케이스도 있어야합니다.
특히 2 번 항목에 대해서는 굉장히 많은 기사를 봤지만 나머지 호출을 처리하는 방법에 대한 샘플 (코드) 접근 방식을 찾을 수 없습니다.
BDD와 TDD는 둘 다 테스트 첫 개발에 사용되지만 서로 비교할 수 없습니다.
BDD는 영어와 같은 구문으로 테스트를 작성하는 것 이상의 기능을합니다. 키위. BDD (ATDD-Acceptance Test Driven Development라고도 함)는 개발자, 품질 보증 및 디자이너 (예 : 비즈니스 및 상호 작용 설계자)와 함께 시작하여 제안 된 솔루션에 대한 공유 된 이해를 개발합니다. 예제를 사용하여 동작을 설명하는 것이 일반적이며, 예를 들어 사양 별이라고도합니다.
추상화에 대해 생각하는 유용한 방법은 자신이하는 일 (추상적, 고급 정책)과 어떻게하는지 (구체적이고 세부적인 세부 사항)를 구별하는 것입니다. 더 높은 수준의 정책을 수행하기위한 모든 구체적인 세부 사항이 있습니다. 구체적인 것을 볼 때, 그것이 제공하는 정책을 식별하는 것이 유익합니다.
예제를 통해 응용 프로그램이 수행하는 동작, 즉 동작을 테스트하는 상위 수준의 수락 테스트를 만들 수 있습니다.
단위 테스트는 앱이 솔루션을 구현하는 방법을 테스트하는 데 사용됩니다. 즉, 해당 메시지가 적절한 시간에 공동 작업자/종속성에 전송되는지 테스트합니다.
표준 TDD주기의 단계는 Red, Green, Refactor입니다. 초록색 단계에서 목표는 가능한 한 빨리 테스트를 통과 시키거나, 훅 또는 사기꾼에 의해 이루어 지므로 추악하고 조직화되지 않은 코드를 작성하는 것이 좋습니다. 테스트가 통과되면 코드를 리팩토링하여 읽기/변경이 가능하도록합니다.
마찬가지로 BDD/ATDD 사이클을 사용하면 Red, Green, Refactor가됩니다. BDD의 초록색 단계에서 합격 판정 테스트를 통과하십시오. 작성한 모든 코드는 테스트 자체 내에 존재할 수 있습니다. BDD의 리팩터 단계에서 테스트 코드를 프로덕션 코드로 추출합니다. TDD를 사용하여 추출을 안내 할 수 있습니다.
따라서 주어진 BDD 수락 테스트의 경우 여러 개의 TDD 테스트가있을 수 있습니다.
REST 호출을 테스트하는 방법에 대해서는 추상화의 전제로 돌아가 봅시다. 우리가하는 일과 구별하는 것입니다.
REST 서비스를 호출하는 것은 구체적인 동작입니다. 그것이 만족하는 정책은 모델 객체들의리스트를 제공하는 것일 수있다.
구현하려는 유스 케이스가 친구를 점심 식사에 초대하는 것이라고 가정 해 보겠습니다. 유스 케이스 책임의 일부는 서버에서 친구 목록을 얻는 것입니다. 서버가 어떻게 친구를 찾는지 상관하지 않습니다.
BDD 테스트는 친구 목록 가져 오기, 친구 선택 및 초대 완료를 처리합니다. BDD 테스트는 REST 호출을 실제로 작성하는 것에 대해 걱정하지 않습니다.
TDD를 사용하여 서버와의 통신을 처리하는 클래스를 구현할 때 원격 데이터 소스 (예 : 서버)에서 JSON을 검색하고 JSON이 User 모델 객체로 올바르게 구문 분석되는지 테스트 할 수 있습니다. 오류 등으로 응답하는 데이터 소스를 포괄하는 테스트를 수행 할 수도 있습니다.
REST를 실제로 호출하는 시점에서 REST를 사용하여 원격 서버의 백엔드 서버와 통신하는 원격 데이터 소스 구현시 당신이 제어하지 않는 구성 요소 (즉, 실제 백엔드 서버)와의 통합을 테스트 할 때 이것을 통합 테스트로 분류 할 것입니다. 통합 테스트에서는 서버가 JSON 데이터를 앱이 기대하는 형식으로 반환하는지 확인하거나 필요한 경우 오류가 반환되는지 확인하면됩니다.
BDD는 실제로 derived from TDD이므로 조금 혼란스럽지 않습니다. BDD는 TDD (또는 ATDD는 전체 시스템에서 사용하는 경우)와 비슷하지만 "Test"라는 단어는 없습니다. 그것은 꽤 강력 할 수 있습니다.
특히 개발자는 비 기술적 인 비즈니스 사람과 시스템에서 수행해야 할 작업에 대해 대화 할 수 있습니다. 또한 기술 전문가라도 클래스를 사용하여 수행해야하는 작업이나 코드 모듈에서 수행해야하는 작업에 대해 대화 할 수 있습니다.
따라서 REST 서비스의 예에서 내가 개발자이고 REST 서비스가 무엇을해야하는지 알고있는 전문가라고 상상할 수 있습니다.
Me : 어떻게해야합니까?
...
당신 : 그것은 기록을 읽게해야합니다.
Me : 좋아요! 기록의 한 예를 들어 주시겠습니까?
당신을 : I이 여기에서 ...
나 : 누군가가 기록을 읽을 수 없습니다해야하는 어떤 상황이 있습니까?
귀하 : 확실한 권한이없는 경우나이 : 좋아, 그래서 나는 짓을했는지 읽기,의는 업데이트를 할 수 있습니다. 일반적인 업데이트의 예를 들어 주시겠습니까?
당신 : 여기 있습니다.
Me : 환상적이며 성공 또는 실패 만 응답하면됩니다. 에이 실패해야하는 시나리오가 있습니까?
귀하 : 기록은 그것이 마지막으로 갱신 된시기를 보여줍니다. 그 동안 다른 사용자가 이미 업데이트 한 경우 제출할 때 실패하게됩니다.
따라서 BDD를 사용하여 REST 서비스와 관련된 모든 시나리오를 탐색 할 수 있습니다. 트릭은 "예를 들어 줄 수 있니?"라고 묻는 것입니다. 그런 다음 구체적인 예제를 얻습니다. 원하는 경우 자동화 할 수 있습니다.대화를 통해 다른 시나리오와 시나리오를 찾지 못할 수도 있습니다.
기술 대상 자동화를 위해 BDD 도구를 사용하지 마십시오! Cucumber, JBehave 등의 BDD 도구는 실제 영어로 작동하므로 코드보다 리팩토링하는 것이 훨씬 어렵습니다. REST 서비스와 같은 일을하는 경우 JUnit, NUnit 등을 사용하십시오. "Given, When, Then"을 주석에 넣거나 작은 DSL을 만들 수 있습니다.
나이 :
그래서 지금 내가 그것을 코딩 있다면, 나는 같은 예를 가질 것, 당신의 REST 호출 실패와 것을 볼 수 있습니다 그래서,이 호출이 실패를 ... 수를 예를 들어 주시겠습니까?
당신 : 물론, 삭제 된 레코드에 액세스하면 실패 할 것입니다.
Me : 삭제 될 수있는 레코드의 전형적인 예를 들려주십시오.
귀하 : 이전에 사용하던 것이 좋습니다.
Me : 좋아, 레코드를 삭제해서는 안되는 상황이 있습니까?
당신 : 예, 이미 발표 된 않다면 ...
등
당신은 내내, 정말 단어 "테스트"를 사용하지 않는 것을 볼 수 있습니다. 테스트는 BDD의 좋은 부산물입니다. 요구 사항의 탐색 및 지정을 위해 더 많이 사용됩니다. BDD의 대화가 가장 중요합니다.
REST에 BDD를 사용하는 예제를 찾는 것이 까다로운 이유는 REST가 고의적으로 단순하고 많은 동작을하지 않기 때문에 두 번째이며 BDD의 시나리오는 일반적으로 구현 측면에서 표현되지 않기 때문에 두 번째입니다. 서비스 또는 시스템이 제공하는 것의 가치에 초점을 맞추는 것 ("기록 읽기").
잘 수행되면 TDD와 ATDD가 정확히 동일합니다. 예제와 시나리오에 대한 대화는 테스트에 대한 것보다 쉽습니다.
BDD와 TDD는 완전히 비교할 수 있습니다. BDD는 TDD에서 직접 파생되어 "test"라는 단어를 제거합니다 (내 대답의 맨 위 링크 참조). "Acceptance Test"에 관해 이야기 할 때, 당신은 그 단어를 "test"로 되돌려 놓습니다. 이것은 처음부터 BDD의 요점을 완전히 무효로합니다! "BDD 테스트"와 같은 것은 없습니다. 예와 시나리오 만 가능하며 자동화 될 수 있습니다. BDD는 클래스에도 사용할 수 있습니다 (첫 번째 BDD 도구 인 JBehave는 원래 JUnit을 대체하기 위해 사용되었습니다). 그것은 BDD = 전체 시스템 이상이고 TDD = 클래스/모듈이지만 일반적인 오해입니다. – Lunivore