我发现的大多数资源都来自2010年，并没有明确回答我对Flash上的测试驱动开发的问题。看到它经常用于游戏等，我想知道如何设置我的测试，以便我可以确保显示对象的行为正常。
我确实从here做了快速的Hello World应用程序来学习TDD的基础知识，但是如果我在游戏中有角色，玩家可以在视觉上改变他的盔甲呢？如何测试装甲是否正确更换？这不像我的addArmor（）函数会返回任何东西......就此而言，如果我们期望从代码中获得该字符的位置，我将如何测试该字符的位置？
我无法绕过Flash应用的整个视觉部分以及如何正确测试它。我希望这不是一个愚蠢的问题，而且我不只是错过了TDD的一个简单的事实或方面，它将完全回答这个问题。
答案 0 :(得分：0)
我正忙着使用TDD编写游戏，我的解决方案如下所示。我的游戏是2D，因此我可以将屏幕表示为一系列字符。我将此数组传递给我的游戏逻辑，然后验证（使用单元测试）数组已被正确修改。
一旦我准备好渲染屏幕，我只将数组传递给图形例程。图形例程只知道数组，并用每个char替换相应的图形块。我不打算单独测试图形例程，因为这很难做到，当你管理它时，你最终会得到一个非常脆弱的测试。相反，我尝试使图形例程尽可能简单。在这种情况下，它实际上是“从阵列中拉出来的地图 - 它到瓦片 - 平铺”。
当我意识到这一点时，我认为基本原则是我的TDD启蒙时刻。您应该使用单元测试来验证您的代码是否正确地从库和您的环境/框架调用代码（以及您的某个模块正在正确地调用另一个模块）。这正是mock / fake对象的设计目标。从单元测试的角度来看，你并不关心drawTile（）或writeFile（）或sendUdpPacket（）函数是否实际绘制了一个磁贴或写入文件或发送了一个数据包。您可以确定如何使用常规（非TDD /单元测试）测试代码调用这些方法，然后您的TDD工作将验证您是否正确地进行了必要的调用。
在你的情况下，当角色穿着盔甲时，它可能在某个地方以数据结构表示。这是您应该使用TDD验证的内容。然后，您的图形可以从您的数据结构中组成。一旦你在视觉上验证了角色现在是用盔甲绘制的，只要你的所有数据级别调用都是TDD，它就不会发生变化。
在此背景下我最喜欢的一句话：
你可以写得很简单，然后显然没有错，或者 复杂的话，没有什么明显的错误。
MTFBWY