BDD 스토리 스타일

Question

Scrum을 사용하여 SOA 시스템을 개발하기 위해 BDD을 사용하려고 시도했으며 스토리를 제작하는 데 두 가지 접근 방식을 사용했습니다.

Approach 1 
    Given Specific Message Type is available 
    And Specific State exists 
    When the Message is processed 
    Then expected resulting state exists 

Approach 2 
    Given a Specific state exists 
    When Specific Message Type is processed 
    Then expected resulting state exists 

예제 중 하나라도 SOA 시스템에 적용되는 경우는 거의 없습니다. 이 모든 경험이나 각 접근법의 결과에 대한 통찰력에 감사드립니다.

declarative rather than imperative stories을 목표로합니다. 처음 메시지 도착은 약간의 필연적 인 느낌을 갖지만 SUT의 이벤트 중심 특성을 설명하지는 못하기 때문에 두 번째 접근 방법이 수용 기준을 적절하게 다루고 있다고 확신하지 못합니다.

Answer 1

이야기의 목표는 고객과 의사 소통하는 것이므로 목표를 홍보하는 모든 스타일이 가장 좋습니다. 이는 팀마다 다를 수 있습니다. 나는 당신의 제안보다는 "어떤 비즈니스 이벤트가 발생할 때"를 선호 할지도 모르지만 나는 당신의 팀을 모른다! '하나의 크기에 맞는 템플릿'을 찾으려면 각 상황에 가장 잘 맞는 템플릿을 사용하십시오. 민첩성의 핵심은 적응할 수있는 능력입니다. 하나의 스타일을 시도하고 작동하지 않는 경우 자유롭게 적응할 수 있습니다.

Answer 2

저는 도서관이나 서비스를 제작할 때마다 서비스 사용자가 원하는 시나리오의 예를 제공하는 것이 유용하다는 것을 종종 알게됩니다. 예를 들어 그래서 : 서버 감안할 때

는 Lieumoney 형제
에 대한 리스크 한도에 대한 정보를 가지고 그리고 우리는 그 한계에서 $ 2m입니다
우리는 그런 그 한계
을 위해 $ 1m로 우리를 데려 EOD의 주문을 처리 할 때 Lieumoney 형제의 지위는 호박색이어야합니다.

메시지의 실제 내용은 특정 금액 및 해당 거래 상대방과의 상호 작용을 반영 할 수 있습니다. 이 기능을 여러 도메인에서 사용할 수 있으며 접근 방법은 도메인 및 메시지의 가용성이 해당 도메인에 따라 다른지 여부에 따라 다릅니다. 수백만 달러를 거래하는 위의 예에서 특정 거래 상대방에 대한 위험 정보를 보유하는 것이 중요 할 수 있으며, 이것이 주일 경우 별도로 호출 할 가치가 있습니다. 예를 들어 아기 토끼를 사면 덜 중요합니다. 우리는 그 다음이 "Rotweiller 애완 동물 제한"에 주문을해야한다 (15 개) 아기 토끼
주문 시스템을 물어 보면 "Rotweiller 애완 동물 제한"을 감안할 때

는
누구보다 $ 2 저렴 아기 토끼 거래되고있다.

특정 사례가 없으면이를 논의하기가 어렵습니다. 그러나 이러한 시나리오를 제공하는 자동화가 API에 직접 이야기하고 실제로 애완 동물이나 Lieumoney 거래와 관련이없는 경우에도 API를 사용하는 방법에 대한 설명서 역할을하는 방법을 알 수 있습니다.