MS RFC 12:C代码单元测试¶
- 日期
2006／02／28
- 作者
乌姆贝托·尼科莱蒂
- 联系
gmail.com上的umberto.nicoletti
- 状态
草稿
概述¶
单元测试是在编程时检查进度和代码正确性的一种简单但有效的方法。MapServer已经有了针对python mapscript的单元测试和功能测试套件，但是缺少代表其核心功能的C代码的单元测试。
这个RFC概述了如何（逐渐）将单元测试添加到通常的MapServer开发周期中，而不必假装开发人员切换到极端编程或采用测试驱动的开发。
Bugzilla和MapServer Dev的1664号问题将用于跟踪代码示例和讨论。
例子¶
Bugzilla上的问题1664附加了一个补丁，它实现了基本的基础设施和一些单元测试来演示功能。补丁是由一个人在6小时内创建的，他不是一个经常使用C语言的程序员。这是为了证明单元测试不会占用开发人员太多的时间，而且一般来说，好处是值得的。
该示例已经支持所有常见的预处理器标志（使用ifdef proj之类的标志），因此只编译和运行相关的测试。这对于避免由于缺少特性而导致的测试失败是必要的（就像在Python单元测试中那样）。
单元测试软件¶
此RFC建议对C语言2.0.x版使用CUnit单元测试库。必须更新配置脚本以反映此新的依赖项，当找不到CUnit时将显示以下或类似文本：“找不到CUnit，禁用C单元测试”。
当cunit可用时，默认情况下可以在编译阶段结束时运行单元测试：这将使用户对刚编译的软件更有信心（大多数是Linux新手，没有编程经验），并有助于捕获明显的错误（如提交cvs时的拼写错误）。
单元测试放在mapserver源的cunit子目录中，并与所有未来版本一起分发。单元测试文件应根据其测试的原始MapServer源文件以及添加的测试后缀来命名：例如，mappool.c文件的单元测试应放在名为mappoolu tests.c的文件中。这些文件可以在后缀中添加字母数字代码，以方便地保持简短（如mappoolu testsu 1.c，mappool_tests_1b.c或mappool_tests_umberto.c）。
使用建议¶
开发人员不需要编写单元测试，但是当他们编写单元测试时，我们建议遵循这个检查表。
开发人员实现新功能¶
她将尝试通过单元测试来重现这个bug；如果这不可能或看起来很困难，她应该考虑在mapserver-dev上询问。单元测试在这个阶段必须失败（如果写入的话）。
她修复了这个bug，并验证了在前一项中编写的测试现在通过了（如果写入的话）
她确认所有其他测试也通过，并且只有在她提交
开发人员添加功能¶
她编写了一个测试来验证新功能（这也可以在后面完成，因为我们已经放宽了需求）
她编写实现所需功能的代码
她现在确认测试通过了
她确认所有其他测试都通过，并且只有在她提交
一般¶
她还将使用通常的预处理器标志来确保只编译和运行当前配置上下文的相关测试。附在问题1664上的例子已经实现了这个特性。
测试特定功能¶
MapServer的某些方面（如数据库连接和GD呈现）本质上很难测试。本节提供了如何在单元测试中处理它们的指导，并将随着新的或更好的解决方案的设计而扩展。
数据库连接¶
数据库连接通常需要一个特定的设置，以使预期的表、数据和可能的其他结构就位。虽然在短期的单元测试中，这应该是一个长期目标，但是可以限制为将SQL查询与预期的查询进行比较。
这很可能需要重构当前的PostGIS代码。
将来，应该提供一个最小的安装脚本来为用户创建和填充数据库（如果她希望这样做的话）。
GD（和其他）渲染引擎¶
从PerlGD模块中获得灵感，必须生成一组图像，然后将其与MapServer生成的图像进行比较。这种操作已经由MSAutoTest套件执行，因此应该努力改进它，而不是实现另一个GD测试套件。
WFS/WMS支持¶
注：作者不是这里的专家
在这种情况下，可以使用单元测试来验证对于某些请求（可能使用MapServer提供的测试数据），MapServer返回的字符串是否等于预期的字符串。
可能需要对现有代码进行重构。
MapScript¶
单元测试应该由mapscript mantainers按照这里给出的指导原则进行开发。
运行单元测试和功能测试（连续集成）¶
现在不是单元测试的一部分，但在透视图中很有用
应该努力开发一个能够
使用不同的配置选项测试MAPServer和各种MAPServer的整体构建/测试
并将这些结果与MSAutoTest套件集成。