게임에서 BDD (Behavior Driven Development)가 사용됩니까?

나는 BDD-Behavior Driven Development에 대해 오랫동안 읽었으며 기능을 코드로 변환하는 것이 정말 쉽고 유용하다는 것을 알았습니다. BDD 사용자는 종종 TDD를 올바르게 수행했다고 부릅니다.

BDD는 비즈니스 가치 (또는 게임 플레이 가치)에서 코드에 이르기까지 소프트웨어 설계를위한 도구입니다.

댄 노스 소개 BDD

이 외에 BDD 및 게임에 대한 자료를 알고 있습니까?

TDD와 같은 BDD (또는 트렌디 한 개발 유행어 패러다임 삽입)는 일부 게임 개발자가 어딘가에서 사용한다고 말하는 것이 안전하지만 아마도 BDD가 실제로 무엇을 의미하는지 알지 못하거나 반드시 알 수는 없습니다. . 문제는 정말 얼마나 많은 사람들이 그것을 사용하고 얼마나 그들이 이 당신에게 중요 할 그것을 사용할 수 있나요?

예를 들어, 내가 일하는 곳에서 우리의 모든 단위 테스트 이름은 Dan North가 당신이 연결 한 기사에서 제안한 것처럼 "문장"입니다. 그것만으로는 우리가 BDD를 사용한다고 말하는 것으로 충분하지 않지만, 아마도 당신이 정말로 관심을 갖는 것입니까?

제 생각에는 스튜디오에서 어떤 유행어를 적용 하느냐가 아니라 전반적인 생산성 및 개발 프로세스 기법에 중점을 두어야합니다. 나는 가장 생산적인 팀이 교리 적으로 모든 "거대한 단어 패러다임"에서 기술을 혼합하고 매칭하는 것을 발견했다. 일부 인터넷 연구에 따르면 일부 인터넷 연구는 하나의 특정 유행어 패러다임으로 구성되어있다.

나는 이것이 애자일 트렌드에서 가장 자주 본다. 자신을 "민첩하게하는"팀으로 인식하는 팀은 프로세스에 대해 유연하지 못한 경향이있다. 전 팀은 거의 항상 생산성이 떨어집니다.

개발 팀은 기계에서 교환 가능한 톱니가 아닌 인간으로 구성됩니다. 그들은 개인으로서 그리고 그들 자신의 독특한 조합으로 유일하게 작동합니다. 효과적인 개발 방법은 인간을 {BDD, Agile, WhateverIsNext} 금형으로 구부리는 것이 아니라 팀이 진행중인 방식을 지속적으로 재평가하여 프로세스의 결함을 보완하고, 깨진 기술을 대체하고, 문제를 강화하는 것입니다 일. 간단히 말해서 타이틀 배송에 중점을두고 "민첩한 것 (또는 무엇이든)"에 집중하지 마십시오.

그렇습니까? 아마도. 저의 의견은 그것이 저수준의 라이브러리에서 잘 작동 할 수 있지만 일반적으로 엔터테인먼트 소프트웨어에 매우 적합하지 않을 것이라고 생각합니다.

편집 : 여기 내 의견에 대한 칭의가 있습니다.

Wikipedia는 BDD를 "소프트웨어 프로젝트에서 개발자, QA 및 비 기술적 또는 비즈니스 참가자 간의 협업을 장려 하는 기술 " 로 정의합니다 . 게임이 '비 기술적 또는 비즈니스 참가자'에 대한 특정 요구를 충족시키기위한 도구로 설계되지는 않았지만 엔터테인먼트를 위해 광범위하게 설계된 응집력있는 작업이라는 점에서 게임은 대부분의 소프트웨어와 다르기 때문에 이미 나쁜 생각처럼 들립니다. "원하는 소프트웨어 행동"에 중점을두고 있지만 기술 수준을 제외하고 게임에는 '원하는 소프트웨어 행동'이 거의 없습니다. 코드의 해당 부분을 확인하는 것은 확실히 장점이 있지만 최종 사용자에게는 보이지 않습니다.

그러나 인간 이해 관계자를 버리고 다른 코드 모듈 간의 계약을 시행하기 위해 BDD를 사용하고 싶다고 가정 해 봅시다. 여기서 내가 볼 수있는 한 일반적인 테스트 중심 개발과 크게 다르지 않습니다. 다음과 같은 이유로 게임에 적합합니다.

테스트는 예상치 않은 개별 이벤트가 발생했는지 확인하는 데 유용합니다. 이것은 이벤트 중심 프로그래밍에서 잘 작동합니다. 동작이 수행되는 대부분의 소프트웨어 환경에서 일부 출력이 생성 된 다음 동작과 결과가 일치하는지 확인하면됩니다. 그러나 게임 소프트웨어는 일반적으로 동작으로 인해 별개의 결과가 아닌 세계 상태의 지속적인 변화가있는 시뮬레이션입니다. 숨겨진 플레이어가 소리를 내면 AI가 나를 사냥하는지 확인하고 싶을 것입니다. 따라서 노이즈가 생성 된 후 AI가 '헌팅'상태인지 확인하는 테스트를 만들 수 있습니다. 그러나 사냥이 효과가 있다는 것을 어떻게 알 수 있습니까? 즉시 확인할 수는 없습니다. 시간이 지남에 따라 볼 수만 있습니다.

또한 테스트 우선 접근 방식은 잘못된 보안 감각을 만들어 사람들이 코드를 실제보다 더 낫게 만들 수 있습니다.

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

테스트 결과가 오탐 (false positive)을 줄 수 있으므로 코드 자체를 확인해야하는 기본적인 요구를 피할 수 없습니다. 그러나 코드 자체를 적절히 확인하면 테스트는 2 차적으로 중요합니다. 내 생각에, 테스트 후에 버그 수정을 테스트하기 위해 테스트를 사용하는 것이 가장 좋습니다.

객체 X와 Y가 함께 작동 할 때 얻을 수있는 결과가 예상과 동일하다는 테스트에는 아무런 이점이 없다고 주장하지 않습니다. 문제는이를 확인하는 가장 효과적인 방법을 사용하고 있는지입니다. 방법에는 공식 검증, 코드 검토, 테스트 우선 방법, 마지막 테스트 방법, 기존 QA 블랙 박스 테스트 또는 예상대로 코드를 사용하고 결과를 관찰하는 것이 포함될 수 있습니다. 마지막 두 옵션은 놀랍게도 대부분 효과적입니다. 왜냐하면 딱딱하지 않은 것처럼 들리지만 대부분의 버그는 일반적인 사용 과정에서 발견되며 자연적인 맥락에서 버그를 이해하는 것이 인공 테스트에서 이해하는 것보다 때로는 쉽습니다. 마구. 이 위에,

요약하면, 테스트 주도 개발은 소프트웨어를위한 훌륭한 선택이 아니라고 생각합니다. 테스트만으로는 소프트웨어 품질을 보장하기에 충분하지 않습니다 (따라서이를 작성하는 데 소요되는 시간을 해당 개발자 시간의 대체 용도와 비교해야 함). 게임은 자동화 된 테스트 사례에 특히 적합하지 않으며, '비즈니스 가치'와 '수락 테스트'를 강조하는 개발 방법에는 특히 적합하지 않습니다.

(내 의견에 동의하지 않더라도 더 나은 답변입니다.)

BDD는 모든 환경에서 적절하다고 생각합니다. 다른 사람들이 언급했듯이 소프트웨어를 개발 중이므로 테스트해야합니다. 테스트 이름과 같은 임의의 의미론을 문장으로 사용하여 bdd를 좋아합니다. 또한 1 개의 클래스를 테스트하면서도 특정 테스트를 그룹화하는 것이 좋습니다.

다른 메시지와 싸우기 위해 더 큰 프로젝트에서는 테스트하지 않고 코드를 리팩터링하는 것이 훨씬 어렵다는 것을 지적하고 싶습니다. 일부 코드를 리팩터링하면 모든 것이 영광의 불꽃 속에서 폭발하는지 여부에 대해 맹목적으로 비행합니다. 시험은 물건을 빨리 잡는 데 도움이됩니다. 따라서 테스트를 작성하고 실패하고 통과하고 계속하기에 충분한 코드를 작성하십시오. 리팩토링 할 때 동일한 작업을 수행해야하지만 쓰기보다는 테스트를 수정해야합니다. 대부분의 경우 테스트를 실행하면 테스트에 실패하고 변경해야 할 사항을 변경해도 여전히 실패합니다. 이 시점에서 다른 코드 조각은이 함수 / 방법에 완전히 다른 방식으로 의존한다는 것을 알고 있습니다. 그런 다음 테스트와 결과 코드를 수정할 수 있습니다. 이런 종류의 코드 범위가 없으면 물건이 부서진 곳을 찾으려고 며칠 동안 걸려 넘어 질 것입니다.

Pragmatic Progammer의 책에서 "계약"에 대해 읽으십시오. 테스트는 코드 계약을 달성하는 데 도움이됩니다. 이 코드는 X를 수행하고 X를 능가하며 Y에 대해 아무것도하거나 Z에 적응하려고하지 않습니다. 코드 청결을 보장하고 모든 사람이 코드 기반을 어지럽히 지 않고 진흙 투성이가되기를 기대합니다.

BDD에는 더 많은 이유가 있습니다. 나에게 가장 중요한 것은 어쨌든 내 가정의 유효성을 검사하기 위해 동일한 양의 테스트를 수행하여 공식화 할 수 있다는 것입니다.

"어떻게"의 시점에서 그것은 실제로 환경에 달려 있습니다. 지금 자바 게임을 작성하고 robolectric을 사용하고 있습니다. 항상 "예상"을 시도해야합니다. 스파이 / 모의 / 스텁은 다른 측면에서 동등한 기능이 필요하기 때문에 유용하지 않지만 때로는 API를 선택할 수없는 경우가 있다고 들었습니다. API의 다른 쪽은 끔찍하지 않으며 일반적으로 코드가 짜증나는 것으로 가정 할 수 있습니다.

예를 들어 움직임을 테스트하는 중입니다. "Up"을 누르면 사용자가 약간의 측정으로 앞으로 나아갈 것으로 예상됩니다.

예를 들어 그래픽 렌더링을 테스트하는 경우 ... 실제로 테스트하기 때문에 너무 많이 테스트하지 않습니까? 좋은 테스트 프레임 워크가이 부분을 처리 할 수 ​​있습니다. 리플렉션은 이런 종류의 것들에 대해 말한 것처럼 사소한 것이 아닙니다. 버퍼 등을 확인해야 할 수도 있습니다. 실제로 실제로 수행중인 작업을 확인하기 만하면됩니다. 성격은 여기에 있으며, 이제 그는 행동을 취한 후에 거기에 있습니다.

작은 기능 / 테스트가 많이 있어야하며 함께 유용한 것으로 요약됩니다.

BDD가 무엇인지에 대한 오해가 있다고 생각합니다. BDD는 테스팅 기법이나 프로세스가 아닙니다. BDD는 개발 모델 및 프로세스입니다. 그것은 테스트 그 이상이며 프로그래밍 그 이상입니다.

따라서이 모델로 작업하는 주요 AAA 스튜디오를 모릅니다 (전 세계에서 프로그래머로 일하는 친구가 있습니다). 다른 사람이 지적했듯이 일부 프로젝트 관리자 또는 팀은 어딘가에 BDD가 포괄하는 관행 중 일부를 통합하고 있지만 비즈니스 가치 정의에서 사양, 예를 들어 글쓰기에 이르기까지 순수한 BDD를 적용하는 스튜디오는 알지 못합니다. 피처 파일을 주주로 검증하고 피처 파일을 테스트로 자동화합니다.