C # / XNA 게임 프로젝트의 단위 테스트


13

프로그래밍을 시작한 이후로 게임 개발에 어려움을 겪었지만 결코 심각하게 생각하지는 않았습니다. 비즈니스 앱 개발자로 일하지만 여가 시간에 일부 게임을하고 있습니다.

비즈니스 세계 (Microsft web-dev 스택)에서 ASP.NET MVC는 인터페이스 작동 방식을 쉽게 단위 테스트 할 수 있기 때문에 인기가 높아지고 있습니다.

모든 게임 로직을 쉽게 단위 테스트 할 수있는 게임을 작성하는 데 사용할 수있는 디자인 패턴 (MVC, MVP, MVVM 등)이 궁금합니다. 이것이 가능하거나 가능합니까? 시간을 낭비하고 있습니까? 전체 빌드를 수행 한 다음 단위 테스트 대신 "통합"유형 테스트를 실행하는 것이 더 낫습니까?

샘플 코드는 훌륭하지만 쓰기 기능도 유용합니다.

(단위 테스트 태그를 추가하려고했지만 담당자가 필요하지 않습니다 ...)

답변:


17

다음은 쉽게 재사용 할 수있을뿐만 아니라 단위 테스트를 훨씬 쉽게 수행 할 수 있도록 기능을 분리하기위한 아키텍처를 설명하는 좋은 기사입니다.

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

일부 게임은 MVC와 유사한 패턴의 혜택을받습니다. 체스 및 카드 게임과 같은 보드 게임이 떠 오릅니다. 그러나 대부분의 경우 이것은 엄청난 과잉입니다.

개인적으로 나는 본질적으로 알고리즘적인 것만 단위 테스트하는 것으로 충분하다는 것을 알았습니다. 게임 플레이 코드를 작성할 때 "정상 작동"에 의존하고 문제가 해결되지 않으면 문제를 추적하기가 어려울 수 있습니다. 교차점 테스트 또는 네트워킹 코드와 같은 것.

(이상적으로는 타사 프레임 워크에 내장되어 있으므로 작성 하거나 테스트 할 필요가 없습니다 !)

단위 테스트 게임 관련 항목에 사용하고 싶은 기술 중 하나는 "시각 단위 테스트"입니다. 기본 개념은 문제 코드의 간단한 라인 렌더링 (예 : 교차 함수) 및 입력을 조작하기위한 일부 기본 키 또는 마우스 지정입니다. 단위 테스트를 자동화 할 필요는 없다고 말하면됩니다. 개별 단위로 분류하고 테스트하기 만하면됩니다.


좋은 대답입니다. 나는 또한 그 기사를 정확하게 게시하고 싶었다. 게임 오브젝트 컴포넌트 시스템은 로직을 분리하고 개별적으로 단위 테스트를 수행 할 수있는 좋은 방법입니다. 그러나 단위 테스트가 할 수없는 것은 무작위로 실시간으로 상호 작용하는 게임 로직의 여러 경로의 복잡한 상호 작용입니다. 그것은 일기 예보를 단위 테스트하려고하는 것과 같습니다. :)
LearnCocos2D

예, 또한 특정 기능을 분리하는 작은 테스터를 만듭니다. API 등을 변경하면 항상 작동하는지 확인합니다. 다음 프로젝트에서 기능을 훨씬 쉽게 재사용 할 수 있습니다.
Iain

3
예, 정답이며 링크가 마음에 듭니다. 그리고 마지막 줄까지 모든 것에 동의했습니다. "아무도 단위 테스트를 자동화 할 필요는 없다" :) 가지고 에 아마 -하지만 모두 내가 한 읽기는 것을 의미한다 (또는 크게 말한다) 단위 테스트를 해야 자동화 할 경우에만 모든 테스트를 실행하는 하나의 버튼을 누르면 점에. 그렇지 않으면 테스트 실행과 관련된 작업이 많을수록 테스트를 자주 실행할 가능성이 줄어 듭니다. 물론 디스플레이 코드 에 대해 이야기하고 있다면 가능하면 단위 테스트가 훨씬 더 어려울 수 있습니다.
Cyclops

거의 4 년이 지났는데 그 이유를 더 잘 이해했다고 생각합니다 "시각 단위 테스트"가 잘 작동 합니다. 단위 테스트는 개발 도구입니다. 전형적인 자동화 된 단위 테스트 뭔가가 있음을 알 수 있다 깨진. 그러나 시각적 단위 테스트를 통해 매우 복잡한 알고리즘을 탐색 할 수 있으며, 특히 라이브 코드 편집과 결합 된 경우 왜 문제 가 발생 했는지 신속하게 파악할 수 있습니다 . 종종 시각적 테스트는 달리 할 거라고 문제를 식별 할 수 있습니다 예상 (: 조정 등)에는 "오른쪽"응답이없는 경우 코드, 또는 문제에 테스트합니다.
Andrew Russell

그리고 단위 테스트를 "충분히"실행해야한다는 아이디어는 항상 자동화 된 방식으로 가짜입니다. 분명히 변경되지 않는 코드는 다시 테스트 할 필요가 없습니다. 코드 수정 될 때 수정을 수행하는 개발자는 사용 가능한 적절한 테스트 (시각적, 코드 기반 또는 기타)를 활용하면서 그렇게해야합니다. 자동화 된 테스트가 가치있는 시간 투자 인 특정 위험 프로파일을 가진 코드가 분명히 존재합니다. 그러나 이러한 시나리오는 게임 개발에서 특히 드물다.
Andrew Russell
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.