带图表的TDD

1. 找出代码的复杂性在哪里。
2. 把它从不稳定的视觉表现中分离出来
3. 测试它

如果你没有任何非视觉的复杂性,你就不是在写程序,而是在创作一件艺术品。

除非您使用的是一个非常糟糕的bug编译器或其他东西,否则我将避免任何归结为“测试源代码按它所说的做”的测试。任何在功能上等同于:

assertEquals (hash(stripComments(loadSourceCode())), 0x87364fg3234);

可以删除而不丢失。

除非您真正了解将要构建的API调用的确切顺序,否则很难为类似这样的可视化内容编写定义的单元测试。

要测试像这样的“视觉”东西,您有三个部分。

1. 一个“尖峰”以获得正确的外观、比例、颜色和所有这些。在某些情况下,这几乎是整个应用程序。

2. 对它的“手动”测试将创建一些最终图像,以确保它们看起来正确。除了实际查看实际输出之外,没有简单的方法来测试这一点。这很难实现自动化。

3. 模拟图形组件以确保应用程序正确调用图形组件。

进行更改时,必须同时运行两个测试:API调用是否都正确?这一系列的API调用是否产生了看起来正确的图像?

你可以——如果你真的想让一个脑细胞爆裂——试着从你的图形和测试中创建一个PNG文件,看看PNG文件是否“看起来”正确。这不值得付出努力。

随着你的前进,你的要求可能会改变。在这种情况下,您可能必须首先重写峰值,并使事情看起来正确。然后,您可以拉出API调用序列,从峰值创建自动单元测试。

有人可能会说,创建尖峰违反了TDD。但是,尖峰设计用于创建可测试的图形模块。你不能轻易地先写测试用例,因为测试过程是“向人展示它”。它不能自动化。

您可以考虑首先将初始输入数据转换为一些可以测试的中间格式。然后将中间格式转发到实际绘图功能,您必须手动测试该功能。

例如,当您有一个程序输入百分比并输出饼图时,那么您可能有一个中间格式来精确描述每个扇区的尺寸和位置。

您已经描述了一个数据模型。应用程序可能会做一些事情,而不是仅仅坐在内存中保存一些数据。编写测试来练习应用程序的行为,并验证结果是否符合预期。