我很好奇,因为我看到的所有TDD示例都与Web编程相关.如果这不是一种正常的方法,为什么不呢？
TDD已成为认真对待自己职业的软件开发人员所青睐的方法.[ IEEE:TDD ]该方法的好处是显着的,相比之下成本较低.[ TDD的三个定律 ]
没有TDD不适合或无效的软件域.但是,有一些领域具有挑战性.游戏恰好是其中之一.
实际上,挑战不是游戏,而是UI.UI面临挑战的原因是,在您看到UI之前,您通常不知道UI的外观.用户界面是你必须摆弄的东西之一.正确的做法是一个深刻的迭代过程,充满曲折,死胡同和后巷.首先为UI 编写测试可能既困难又浪费.
现在,在每个人都咆哮之前说:"鲍勃叔叔说:'不要为用户界面制作TDD'"让我这样说.难以为UI做纯TDD的事实并不意味着你几乎不可能为其他所有东西做纯TDD.大部分游戏都是关于算法的,你可以将TDD与这些算法结合使用,让你心满意足.这是真的,尤其是在游戏,其中有些算法是你必须拨弄样的代码,就像UI,所以很可能是不适合被测试第一.但是还有很多其他算法代码可以而且应该首先编写测试.
这里的诀窍是遵循单一责任原则(SRP)并将那些你必须使用的代码分开,从那些确定性的代码中分离出来.不要在UI中放入易于测试的算法.不要将您的推测代码与非推测性代码混合在一起. 保持因理性而改变的事物与因理由B而改变的事物分开.
此外,记住这一点:有些代码是难以测试的事实第一,并不意味着这个代码是很难测试第二.一旦你进行了调整和调整并让代码按你喜欢的方式工作,那么你可以编写测试来证明代码的工作方式与你的思维方式相同.(在执行此操作时,您会发现错误的次数,您会感到惊讶.)
在"事后"编写测试的问题在于,代码经常如此耦合,以至于很难编写最有用的手术测试.因此,如果您正在编写首先难以测试的代码类型,则应注意遵循依赖性反转原则(DIP)和开放/封闭原则(OCP)以保持代码解耦,以便在之后进行测试事实.
简单的答案是"不",TDD不是游戏开发中的常规方法.有些人会指出Highmoon和Neil Llopis作为反例,但这是一个很大的行业,他们是我所知道的唯一完全接受TDD的人.我确信还有其他人,但他们是我所知道的唯一(我已经在这个行业工作了5年).
我想我们很多人已经在某个时候涉足单元测试,但由于某种原因,它还没有成功.从个人经验来看,游戏工作室很难转向TDD.通常,代码库从一个项目到另一个项目保持不变,并且将TDD应用于大型现有代码库既繁琐又基本上没用.我确信最终它会证明是富有成效的,但让游戏编码员购买它很困难.
我在为低级游戏引擎代码编写单元测试方面取得了一些成功,因为这些代码往往具有很少的依赖性并且很容易封装.这一直是在事实之后进行测试,而不是TDD.更高级别的游戏代码通常更难编写测试,因为它具有更多的依赖性,并且通常与复杂的数据和状态相关联.以AI为例,测试AI需要某种上下文,这意味着导航网格和世界上的其他对象.单独设置这种测试可能并非易事,特别是如果所涉及的系统不是为它而设计的.
在游戏开发中更常见的是,我有更多的个人成功,是烟雾测试.您经常会看到烟雾测试与持续集成结合使用,以提供有关代码行为的各种反馈.烟雾测试更容易,因为它可以通过将数据输入游戏并回读信息来完成,而无需将代码划分为微小的可测试部分.再次以AI为例,您可以告诉游戏加载一个级别并提供一个脚本来加载AI代理并为其提供命令.然后,您只需确定代理是否执行这些命令.这是一个冒烟测试,而不是单元测试,因为您是整个游戏而不是单独测试AI系统.
在我看来,通过单元测试低级代码,同时冒烟测试高级行为,可以获得不错的测试覆盖率.我认为(希望)其他工作室也采取类似的方法.
如果我对TDD的看法听起来有些含糊不清,那是因为它.关于它,我仍然有点蠢蠢欲动.虽然我看到了一些好处(回归测试,在代码之前强调设计),但在使用预先存在的代码库时应用它并强制执行它似乎是一个令人头痛的秘诀.
来自Within的游戏有一篇文章讨论了他们对单元测试的使用,特别是关于游戏的单元测试的局限性,以及他们为帮助实现此目的而设置的自动化功能测试服务器.
如果你指的是为每一段代码编写和维护单元测试的做法,我冒昧地猜测并说明这在游戏行业中并没有广泛使用.这有很多原因,但我可以想到3个明显的原因:
文化.程序员是保守的,游戏程序员加倍.
实际的.TDD不适合问题域(运动部件太多).
Crunchological.从来没有足够的时间.
TDD范例在应用领域中效果最好,这些应用领域不是非常有状态,或者至少在移动部件不是同时移动的情况下,通俗地说.
TDD适用于游戏开发过程的一部分(基础库等),但这项工作中的"测试"通常意味着运行自动飞行,随机密钥测试,定时负载,跟踪fps尖峰,确保玩家可以不要动摇他的方式导致视觉不稳定,像这样的东西.自动机也经常是人形机器人.
TDD可以是一个有用的工具,但它作为一个必须无处不在的银弹的地位 - 在制造系统时是相当可疑的.发展不应该由测试驱动,而是由理性驱动.RDD虽然是一个糟糕的缩写 - 它不会流行起来.;)
京公网安备 11010802040832号 | 京ICP备19059560号-6 