단위 테스트가 용이하도록 게임 소프트웨어를 설계하는 방법은 무엇입니까?

게임 개발 상황에서 JUnit과 같은 테스트 프레임 워크를 사용하는 것이 실용적입니까? 게임을 더욱 테스트하기 위해 어떤 종류의 디자인 고려 사항을 따를 수 있습니까? 게임의 어떤 부분을 테스트 할 수 있고 어떤 부분을 인간의 테스트에 맡겨야합니까?

예를 들어, 게임 루프가 하나의 기능으로 캡슐화되어 있으면 테스트하기가 매우 어려울 것 같습니다. 나는 시간 델타를 취하고 게임 로직을 발전시키는 "업데이트"기능을 리팩토링하고 싶다. 이것은 가짜, 느린 시간 델타를 공급함으로써 게임 속도를 늦출 수있는 능력과 같은 흥미로운 트릭을 허용합니다.

TDD의 신조 중 하나는 경우에 따라 TDD가 설계에 영향을 미친다는 것입니다. 시스템에 대한 테스트를 작성한 다음 테스트를 통과하도록 코드를 작성하고 종속성을 가능한 한 얕게 유지하십시오.

나에게 단위 테스트의 일부로 테스트하지 않는 것은 두 가지뿐입니다.

먼저 시각적 요소와 사물이 어떻게 보이는지 테스트하지 않습니다. 테스트 후 객체가 올바른 위치에 있는지 테스트하고 카메라가 경계 외부의 객체를 컬링하고 변환 (적어도 셰이더 외부에서 수행되는 객체)이 그래픽 엔진에 전달되기 전에 올바르게 수행되는지 테스트합니다. 그래픽 시스템에 도달하면 선을 그립니다. DirectX와 같은 것을 조롱하는 것을 좋아하지 않습니다.

둘째, 메인 게임 루프 기능을 실제로 테스트하지는 않습니다. 합리적인 델타를 통과하면 모든 시스템이 작동하고 필요할 때 올바르게 작동하는지 테스트합니다. 그런 다음 게임 루프에서 각 시스템을 올바른 델타로 업데이트합니다. 실제로 각 시스템이 올바른 델타로 호출되었음을 보여주는 테스트를 할 수는 있지만 많은 경우에 (필요한 델타를 얻기 위해 복잡한 논리를 수행하지 않는 한 과잉이 아님) 과도한 것을 발견합니다.

Noel Llopis는 여러분이 찾고 있다고 생각하는 정도까지 단위 테스트를 다루었습니다.

• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-2
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-3
• http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• (그는 또한 TDD에 관한 많은 다른 기사를 가지고 있습니다)

전체 게임 루프를 테스트하는 것과 관련하여 코드에서 기능적 회귀를 방지하는 또 다른 기술이 있습니다. 아이디어는 재생 시스템을 통해 게임 자체를 재생하는 것입니다 (즉, 먼저 플레이어 입력을 기록한 다음 다른 런을 통해 재생). 재생하는 동안 모든 프레임에 대한 각 객체 상태의 스냅 샷을 생성합니다. 이 상태 모음을 "골든 이미지"라고합니다. 코드를 리팩터링 할 때 다시 재생을 실행하고 각 프레임의 상태를 골든 이미지 상태와 비교하십시오. 다르면 테스트에 실패한 것입니다.

이 기술의 이점은 분명하지만 다음과 같이주의해야 할 사항이 있습니다.

• 게임은 결정 론적이어야하므로 시스템 시계, 시스템 / 네트워크 이벤트, 결정적으로 시드되지 않은 난수 생성기에 따라주의를 기울여야합니다. 기타
• 골든 이미지가 생성 된 후 컨텐츠가 변경되면 골든 이미지와 합법적 인 차이가 발생할 수 있습니다. 이 문제를 해결할 방법이 없습니다. 콘텐츠를 변경할 때 골든 이미지를 재생성해야합니다.

나는 Jeff와 jpaver의 의견에 모두 동의합니다. 또한 아키텍처에 구성 요소 모델을 채택하면 테스트 가능성이 크게 증가한다고 덧붙였습니다. 구성 요소 모델을 사용하면 각 구성 요소는 단일 작업 단위를 수행해야하며 격리 된 상태에서 (또는 제한된 모의 객체로) 테스트 할 수 있어야합니다.

마찬가지로, 개체에 의존하는 게임의 다른 부분은 작동하기 위해 구성 요소의 하위 집합에만 의존해야합니다. 실제로 이것은 일반적으로 이러한 영역을 쉽게 테스트하기 위해 몇 가지 가짜 구성 요소를 조롱하거나 테스트 목적으로 부분 엔티티를 구성 할 수 있음을 의미합니다. 예를 들어, 렌더링 및 입력 컴포넌트는 물리 테스트에 필요하지 않기 때문에 생략합니다.

마지막으로, 인터페이스에 관해 게임 커뮤니티의 일부 사람들이 얻는 성능에 관한 조언을 무시하겠습니다. 인터페이스로 코드를 작성하고, 성능 문제가 발생하면 쉽게 프로파일 링, 식별 및 리팩토링하여 문제를 해결할 수 있습니다. 인터페이스의 성능 영향 또는 인터페이스의 복잡성 오버 헤드에 대한 Noel의 우려에 대해서는 설득력이 없었습니다.

즉, 모든 작은 것을 독립적으로 테스트하려고 시도하지 마십시오. 대부분의 테스트와 디자인은 올바른 균형을 유지하는 것입니다.

사용자가 단위 테스트를 대체 할 수 있다는 OP의 의견에 응답하는 두 번째 답변을 추가 할 것이라고 생각했습니다. 단위 테스트의 목적이 품질을 보장하지 않기 때문에 이것이 완전히 잘못되었다고 생각합니다. 프로그램의 품질을 보장하기 위해 테스트를 실시하려면 시나리오 테스트를 조사하거나 훌륭한 모니터링에 투자해야합니다.

(모니터링 및 서비스로 실행되는 제품을 사용하면 실제로 "테스트"를 고객에게 푸시 할 수 있지만 오류를 신속하게 감지하고 변경 사항을 롤백하는 정교한 시스템이 필요합니다. 소규모 개발팀.)

단위 테스트의 주요 이점은 개발자가 더 나은 코드를 작성하도록 강요한다는 것입니다. 테스트는 개발자가 우려 사항을 분리하고 데이터를 캡슐화하도록 요구합니다. 또한 개발자가 인터페이스와 다른 추상화를 사용하여 한 가지만 테스트하도록 권장합니다.