디자인이나 분석에 대한 행동 중심 개발이 있습니까?

Question

BDD와 그것이 TDD를 어떻게 개선해야 하는지에 대해 더 많이 읽을수록 모든 것이 더 혼란스러워 보입니다.디자인에 관한 전문가의 인용문뿐만 아니라 분석에 관한 다른 전문가의 인용문도 찾았습니다.

현재 제가 보는 방식은 이렇습니다.

1) 분석:BDD

~에서 위키피디아

객체 지향 분석의 결과는 개념적 모델의 형태로 시스템이 기능적으로 수행 해야하는 내용에 대한 설명입니다.

따라서 BDD 이후에는 요구 사항(스토리 및 시나리오)이 있습니다.하지만 개념적 모델 부분에 대해서는 잘 모르겠습니다.

2) 디자인:예: CRC 카드를 사용한 공명 중심 설계와 같은 도구 사용

3) 코드:디자인 코딩, 선택적으로 테스트 사용(TDD가 잘못되었다고 말하는 것과 같은 것, 나도 유용하다고 생각함)

내가 이것을 어떻게 보는가?지금은 나무를 통해서 숲을 보는 데 어려움을 겪고 있습니다.

Answer 1

요컨대와 관련이 있습니다 분석.

BDD는 "수락 테스트 중심 개발"을위한 것입니다. 즉, 테스트중인 시스템이 특정 사용자 스토리 시나리오에 대해 예상대로 작동하는지 알기위한 것입니다.

JBEHAVE와 함께 일할 때 사용자 스토리 수준에서 사용했으며 개별 객체와 하위 시스템 간의 협업을 처리하기 위해 여전히 "기존"TDD를 수행했습니다.

일반적으로 비즈니스 시스템은 BDD 시나리오를 사용하여 시스템 내부의 작은 구현 세부 사항을 테스트하지 않기 위해 비즈니스 도메인 동작을 설명합니다. 도메인 전문가의 추상화 수준에서 BDD 시나리오가 투구되기를 원합니다. 이러한 시나리오는 도메인 전문가에게는 의미가 없으며 구현의 모든 작은 세부 사항을 설명하면 매우 취약합니다.

BDD 시나리오가 말합니다 무엇 시스템은 사용자 스토리를 위해해야합니다 그러나 방법은 아닙니다 그것은 그것을한다.

Answer 2

BDD는 "실행 가능한 사양"또는 수락 테스트 AKA에 관한 것입니다. 블랙 박스 테스트 정의상, 테스트 사례를 도출하기 위해 테스트 객체의 외부 관점을 취합니다..

따라서 BDD는 설계에 관한 것이 아니며 BDD는 기능/스토리/시나리오 테스트에 관한 것입니다. BDD는 분석에 더 가깝습니다.

Answer 3

BDD- 행동 중심 개발

행동 = ..의 맥락에서 .. 개발 - ... ...의 구성에서 ...

이 경우 개발은 분석이 수행되었고 특정 행동의 맥락에서 무언가를 구현하고 있음을 나타냅니다.

그래서 질문에 대답하기 위해 설계.

Answer 4

아키텍처에서 POV BDD는 디자인에 관한 것이라고 생각합니다. 나는 무언가를 할 수있는 응용 프로그램을 설계해야하며 나중에 수락 테스트에 사용됩니다. 따라서 높은 수준의 디자인에서 나는 다양한 행동 요구 사항을 설계하고 있는지 확인하여 과도하게 디자인하지 않고 복제를 제한하고 싶습니다.

사용자가 실제로보고 싶은 내용, 응용 프로그램의 수행 방법에 대해 더 많은 시간을 할애 할 수 있으므로 재 설계 할 필요가 없도록하는 데 도움이됩니다.

Answer 5

BDD(또는 TDD)는 그렇지 않습니다. ~에 대한 아무것.분석을 지원하는 기술(BDD의 경우 더 많은 접근 방식)입니다. 그리고 디자인(성가신 작은 구현 단계도 포함).TDD와 관련된 "빨간색, 녹색, 리팩터링"이라는 문구를 자주 듣게 되므로 BDD에도 적용됩니다.테스트를 생성하고 실패하는지 확인하고, 코드베이스를 업데이트하여 테스트를 통과한 다음 통과한 테스트를 유지하면서 시스템을 개선된 형태로 재작업하세요.

따라서 BDD는 테스트를 만들 때 분석을 지원합니다.테스트나 예제의 형태로 필요한 동작을 설명해야 합니다.테스트를 실행할 때 디자인을 지원합니다.설계 결정은 필요한 동작을 실수로 중단하는 것을 방지하고 분석에 따라 안내될 수 있습니다.하지만 이는 분석이나 설계를 수행하지 않습니다.아직도 생각해야 합니다.이는 분석 및 설계 단계에서 자신과 모순되지 않도록 하는 방법입니다.

Answer 6

BDD와 TDD는 실제로 사용되는 것을 실제로 다루지 않기 때문에 매우 운이 좋은 이름을 가지고 있습니다.

• DEV주기 동안 가능한 모든 코너 케이스에 대한 테스트를 작성하고 싶지는 않습니다.
• 회귀를 원하지 않으며이 반복을 지우는 데 필요한 코드를 작성하여 반복 가능한 결과를 원합니다.
• 처음에는 상세한 디자인을 할 필요가 없지만 이번에는 완료하고 싶은 몇 가지 요구 사항을 적어야합니다.

BDD/TDD 작성하려는 코드를 설명하는 약간의 코드를 갖기 전에 코드 줄을 쓰지 않으면 2 중 어느 것도 괜찮습니다. 그렇게하면 당신은 구역에 들어갈 것입니다.
BDD/TDD가 DEV 속도를 향상시킬 것이라는 증거는 없지만 (대부분은 그렇지 않을 가능성이 높습니다) 입증 된 소프트웨어를 공개 한 후에 돌아온 문제의 수를 크게 줄일 수 있습니다.

BDD는 TDD가이를 완화하는 모든 것을 테스트 해야하는 압력을 가하는 TDD의 진화이며 내부가 바뀔 가능성이 높기 때문에 수업의 대중 행동 만 테스트해야한다고 말합니다.

BDD는 분석에 관한 것만 큼 디자인에 관한 것이지만, 그것이 당신의 질문이라고 생각하지 않습니까? 스토리를 흐름도 및 건축 다이어그램으로 변환하는 방법을 알고 싶습니까?

내가 당신의 질문에서 얻은 것은 당신이 큰 디자인을 선점하고 코딩하려고한다는 것입니다. 스토리를 만족시키면서 단편적인 방식으로 작성해야 할 것이기 때문에 코드와 아키텍처를 자동으로 얻을 수 있기 때문에 BDD는 작동하지 않습니다. 이를 응급 설계라고 불리우므로 큰 계획 단계가 없습니다.

스크럼이나 현명한 시스템에서 이것은 비즈니스가 당신의 이야기를 우선 순위로 삼기 때문에 실제로 잘 작동합니다. 맨 위에서 시작하여 사양/예제를 작성한 다음이 백 로그 항목을 완료 한 다음 다음 단계를 선택하고 다시 시작할 때 까지이 예제를 반복하는 예제를 만족 시키십시오.

나는 이것이 당신의 질문에 답하기를 바랍니다. 그렇지 않다면 그것이 Braod 주제이기 때문에 조금 명확히해야합니다. 간단히 말해서 BDD는 순전히 건축가가 아닌 개발자 도구입니다. 테스터는 BDD 도구를 사용할 수 있지만 응용 프로그램을 테스트하는 데 사용하는 유일한 도구가 아니기를 바랍니다.