테스트 주도 개발은 게임 개발에서 일반적인 접근 방식입니까?

Question

전 단지 TDD 예제를 보았 기 때문에 궁금합니다. 웹 프로그래밍과 관련된 것입니다. 정상적인 접근 방식이 아니라면 왜 그렇지 않습니까?

Answer 1

TDD는 자신의 직업에 대해 진지한 소프트웨어 개발자가 선호하는 방법이되었습니다. [IEEE:TDD] 접근 방식의 이점은 상당하며 비용은 상대적으로 낮습니다. [The Three Laws of TDD]

TDD가 부적절하거나 비효율적 인 소프트웨어 도메인이 없습니다. 그러나 도전적인 영역이 있습니다. 게임은이 중 하나입니다.

사실, 도전은 UI만큼 게임 적이 아닙니다. UI가 어려운 이유는 사용자가 보았을 때까지 UI가 원하는 모습을 알지 못하는 경우가 종종 있기 때문입니다. UI는 당신이해야 할 것들 중 하나입니다.올바른 방향으로가는 것은 뒤틀림과 막 다른 길, 뒷 골목으로 가득 찬 반복적 인 과정입니다. UI에 대한 첫 번째 테스트 작성은 어려우며 낭비가 될 수 있습니다.

모두가 소리를 지르기 전에 다음과 같이 말합니다. "Bob 삼촌은 UI에 TDD를 사용하지 마십시오."라고 말하게했습니다. UI를위한 순수한 TDD를하는 것이 어렵다는 사실은 다른 모든 것들에 대해 순수한 TDD를 할 수 없다는 것을 의미하지는 않습니다. 게임에 관한 많은 부분이 알고리즘에 관한 것이며, 이러한 알고리즘을 사용하여 TDD를 마음껏 즐길 수 있습니다. 특히 게임에서 이러한 알고리즘 중 일부는 사용자 인터페이스와 마찬가지로 코드를 작성해야하기 때문에 첫 번째로으로 처리 할 수 ​​없습니다. 하지만 먼저 테스트를 작성할 수 있고 작성해야하는 알고리즘 코드가 많이 있습니다.

여기에있는 속임수는 single responsibility principle (SRP)을 따르고 결정적인 종류에서 피들이를해야하는 코드 종류를 분리하는 것입니다. UI에 테스트하기 쉬운 알고리즘을 넣지 마십시오. 투기 코드와 비추설 코드를 섞지 마십시오. 이유에 따라 변경되는 사항은 이유 B 변경 사항과 별도로 유지하십시오. B. 또한

,이 점을 명심 : 사실을 몇 가지 코드가 처음을 테스트하기 어려운 것으로,이 코드는 초을 테스트하기 어려운 것은 아닙니다. 일단 당신이 원하는대로 작동하도록 코드를 조정하고 조정하고 얻은 후에는 다음 코드를 작성하면 코드가 생각했던대로 작동한다는 것을 증명할 수 있습니다. (이 작업을 수행하는 동안 몇 번이나 버그를 발견하게 될지 놀랍니다.

"사실 이후"라는 테스트의 문제점은 종종 코드가 너무 결합되어 여러 종류의 외과 수술을 쓰는 것이 어렵다는 것입니다 가장 도움이되는 테스트. 따라서 코드 을 먼저 테스트하기 어려운 종류의 코드를 작성하는 경우 dependency inversion principle (DIP) 및 open/closed principle (OCP)을주의 깊게 살펴보고 사실을 테스트 할 수 있도록 코드 분리를 유지해야합니다.

Answer 2

TDD는 실제로 아직 비교적 새롭지 만 보편적으로 이해되거나 받아 들여지지 않아 아직 어디에서나 '정상적인'접근 방식이 아닙니다. 그것은 지금 어떤 상점들이 그런 식으로 작동하지 않는다는 것을 말하는 것은 아니지만 나는이 시점에서 그것을 사용하는 누군가를 듣기 위해 아직도 놀란다.

Answer 3

게임에서 단위 테스트의 사용, 특히 게임과 관련된 단위 테스트의 제한 사항 및이를 지원하도록 설정 한 자동 기능 테스트 서버에 대해 논의하는 an article이 있습니다.

Answer 4

대부분의 게임 개발자는 현대적인 개발 실무 측면에서 정확하지 않습니다. 고맙게도.

그러나 테스트 주도 개발 모델은 무엇인가를 먼저 사용하고 어떻게 사용하는지 집중적으로 강조합니다. 일반적으로 특정 기능이 실제로 수행하는 작업 (예 : 게임)에 실제로 집중할 수 있도록하기 때문에 일반적으로 잘 수행됩니다.

좋은 게임 개발자는 자연스럽게 이렇게합니다. 그냥 명시 적으로.

Answer 5

코드의 모든 부분에 대해 단위 테스트를 작성하고 유지하는 관행을 말하는 경우, 나는 이것이 게임 산업에서 널리 사용되지 않는다고 추측하고 설명합니다. 여기에는 여러 가지 이유가 있지만 3 가지 확실한 것들을 생각해 볼 수 있습니다 :

• Cultural. 프로그래머는 보수적인데, 게임 프로그래머는 그렇게 두 배나 많습니다.
• 실용적. TDD는 문제 영역 (너무 많은 움직이는 부분)에 잘 맞지 않습니다.
• Crunchological. 시간이 충분하지 않습니다.

TDD 패러다임은 상태가 좋지 않은 응용 프로그램 영역이나 적어도 움직이는 부분이 모두 동시에 움직이지 않는 곳에서는 구어체로 표현하는 것이 가장 좋습니다.

TDD는 게임 개발 프로세스 (기초 라이브러리 등)의 일부에 적용 할 수 있지만이 작업 라인에서의 "테스트"는 일반적으로 자동화 된 플라이 쓰루, 임의 키 테스트, 타이밍로드, 트래킹 fps 스파이크, 플레이어가 시각적 인 불안정을 야기 할 수는 없다고 확신 할 수 있습니다. 오토 마톤은 또한 종종 휴머노이드입니다.

TDD는 유용한 도구 일 수 있지만 시스템을 만들 때 반드시 있어야 할 은색 총알의 상태는 다소 의문의 여지가 있습니다. 개발은 테스트에 의해 유도되어서는 안되며, 이유에 의해 이루어져야합니다. RDD는 엉뚱한 두문자어입니다. ;)

Answer 6

@ 룬 다시 한번 'T'가 아닌 'D'를 강조하십시오. 단위 수준에서 테스트는 당신이 원하는 것을 이해하고 드라이브 코드의 디자인을 이해하는 데 도움이되는 사고 도구입니다. 확실히 유닛 레벨에서, 나는 더 깨끗하고 견고한 코드로 끝난다. 내가 시스템에 넣은 조각의 품질이 좋을수록 더 적은 수의 버그 (함께는 아니지만)와 잘 어울립니다.

게임이 필요로하는 일종의 심각한 테스트와 같은 것은 아닙니다.

Answer 7

아마 주된 이유는 TDD가 더 많은 도움이되는 언어를 사용하는 사람들에게 선호된다는 것입니다. 그러나 그 외에도 게임 자체는 어쨌든 패러다임에 맞지 않습니다.

일반적으로 말하자면 (일반적으로 말하자면, 반례문을 사용하지 마십시오.) 테스트 중심 디자인은 이벤트 기반 시스템에 가장 적합하고 시뮬레이션 스타일 시스템에는 적합하지 않습니다. 테스트 주도형 또는 단순한 단위 테스트 중 어느 것에서도 게임의 하위 레벨 구성 요소에 대한 테스트를 사용할 수는 있지만 더 높은 수준의 태스크의 경우 확정적인 결과로 시뮬레이션 할 수있는 이산 이벤트는 거의 없습니다.

예를 들어 웹 응용 프로그램은 일반적으로 매우 다른 입력 (HTTP 요청)을 가지며 매우 적은 양의 상태 (예 : 데이터베이스의 레코드)를 변경하고 대부분 결정적 출력을 생성합니다 (예 : HTML 페이지). 이것들은 유효성을 쉽게 체크 할 수 있으며 입력을 생성하는 것이 간단하기 때문에 테스트를 작성하는 것이 쉽습니다.

그러나 게임을 사용하면 입력을 시뮬레이트하기가 어려울 수 있습니다 (특히 특정 지점에서 발생해야하는 경우 ... 로딩 화면, 메뉴 화면 등을 지나치는 것을 생각하십시오). 변경하는 상태의 양은 대형 시스템 (예 : 물리 시스템 또는 복잡한 반응 형 AI) 및 출력이 거의 결정적이지 않은 경우 (예 : 난수 사용이 주요 원인이지만 부동 소수점 정밀도 손실 같은 것이 하드웨어 사양과 다를 수 있지만 사용 가능한 CPU 시간 또는 백그라운드 스레드의 성능 등).

TDD를 수행하려면 특정 이벤트에서 정확히 볼 수있는 것을 정확히 알고 정확한 측정 방법을 가지고 있어야하며이 두 가지 모두 이산 이벤트를 피하는 시뮬레이션에서는 어려운 문제이며 의도적으로 무작위 요소, 서로 다른 기계에서 다르게 작동하며 그래픽 및 오디오와 같은 아날로그 출력을 제공합니다.

또한 프로세스 시작 시간이라는 큰 실용적인 문제가 있습니다. 테스트하고자하는 많은 것들은 대량의 데이터를로드해야하며, 데이터를 모의한다면 알고리즘을 테스트하지 않는 것입니다. 이를 염두에두고 개별 작업을 수행하는 모든 종류의 테스트 스 캐 폴딩을 사용하는 것은 신속하게 비실용적입니다. 매번 웹 서버를 다운시키지 않고도 웹 서버에 대한 테스트를 실행할 수 있습니다. 임베디드 스크립팅 언어로 테스트하지 않는 한 게임에서는 거의 불가능합니다 (이는 합리적이고 업계에서 실제로 수행됩니다).

예를 들어, 게임 내 건물에 체적 그림자 렌더링을 추가하려고합니다. 따라서 필요한 하위 시스템 (예 : 렌더러, 게임, 리소스 로더)을 시작하고 건물 (메쉬, 재료/텍스처 포함)에로드하고 카메라에로드하고 해당 카메라를 다음 위치에 배치하는 테스트를 작성해야합니다. 건물을 가리키고, 그림자를 활성화하고, 장면을 렌더링 한 다음 그림자가 실제로 프레임 버퍼에 나타나는지 여부를 어떻게 든 결정합니다. 실용보다 적습니다. 실제로 게임의 형태로이 모든 스캐 폴딩을 이미 가지고 있으며 코드 자체 내의 어설 션 외에도 시각적 테스트를 수행하기 위해 실행합니다.

Answer 8

간단한 대답은 "아니오"이며, TDD는 일반적인 게임 개발 방식이 아닙니다. 어떤 사람들은 Highmoon과 Neil Llopis를 반대 사례로 삼을 것입니다. 그러나 그것은 큰 산업이며 TDD를 완전히 받아 들인 유일한 사람들입니다. 나는 다른 사람들이있을 것이라고 확신하지만, 내가 아는 유일한 사람들이다 (그리고 나는 5 년 동안 업계에 있었다).

나는 우리 중 많은 사람들이 단위 테스트에서 약간의 시간이 걸렸다 고 생각하지만, 한 가지 이유 또는 다른 이유로 그것은 잡히지 않았다. 개인적인 경험으로 말하면 게임 스튜디오는 TDD로 전환하기가 어렵습니다. 보통 코드베이스는 프로젝트마다 유지되며 TDD를 큰 기존 코드베이스에 적용하는 것은 지루하고 크게 감사하지 않습니다. 결국에는 효과가있을 것이라고 확신하지만, 게임 코더를 구입하는 것은 어렵습니다.

저수준 게임 엔진 코드에 대한 단위 테스트를 작성하는 데 약간의 성공을 거뒀습니다.이 코드는 종속성이 거의없고 캡슐화가 쉽기 때문입니다. 이것은 항상 TDD가 아닌 사실 이후에 테스트되었습니다. 더 높은 수준의 게임 코드는 훨씬 더 많은 의존성을 가지고 종종 복잡한 데이터와 상태와 관련되기 때문에 테스트를 작성하기가 일반적으로 어렵습니다. 예를 들어 인공 지능을 테스트하기 위해 AI를 사용하려면 일종의 컨텍스트가 필요합니다. 즉, 세계의 네비게이션 메쉬 및 기타 개체를 의미합니다. 이러한 종류의 테스트를 독립적으로 설정하는 것은 중요하지 않을 수 있습니다. 특히 관련된 시스템이이를 위해 설계되지 않은 경우에는 특히 그렇습니다.

게임 개발에서 더 일반적인 것은 무엇이며, 개인적으로 성공을 거뒀습니다. 연기 테스트입니다. 코드의 동작에 대한 다양한 피드백을 제공하기 위해 연속 통합과 함께 연기 테스트가 사용되는 경우가 종종 있습니다. 연기 테스트는 코드를 작은 테스트 가능한 부분으로 분류하지 않고도 게임에 데이터를 입력하고 정보를 다시 읽음으로써 수행 할 수 있기 때문에 더 쉽습니다.예를 들어 AI를 다시 사용하면 레벨을로드하고 AI 에이전트를로드하고 명령을 제공하는 스크립트를 제공하도록 게임에 지시 할 수 있습니다. 그런 다음 에이전트가 해당 명령을 수행하는지 여부 만 결정하면됩니다. 이것은 전체적으로 게임을 실행하고 AI 시스템을 개별적으로 테스트하지 않기 때문에 단위 테스트가 아닌 연기 테스트입니다.

제 생각에는 낮은 수준의 코드를 테스트하면서 단위 테스트를 수행하고 높은 수준의 동작을 테스트하는 것이 가능합니다. 다른 스튜디오에서도 유사한 접근 방식을 취하고 있다고 생각합니다.

TDD에 대한 제 의견이 다소 모호한 이유는 그것이 그렇기 때문입니다. 나는 아직도 그것에 관한 울타리에 다소있다. 기존 코드베이스로 작업하면서 몇 가지 이점 (회귀 테스트, 코드에 대한 디자인 강조)을 적용하고이를 적용하는 것은 두통의 처방처럼 보입니다.