带有图表的测试驱动开发

Question

我有一个绘制图表的应用程序。该图遵循一定的模式，

例如，形状X在形状Y内，形状{X，Y}属于组P ...

图表可能会变得又大又复杂(想想电路图)。

为这个应用编写单元测试的好方法是什么？

Answer 1

1. 找出代码中的复杂性所在。从无法测试的可视化presentation
2. test it

中分离出来。

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

除非你使用的是一个错误严重的编译器或者别的什么，否则我会避免任何归结为“测试源代码做它所说的事情”的测试。在功能上等价于以下各项的任何测试：

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

可以无损失地删除。

Answer 2

很难为这种可视化的东西编写已定义的单元测试，除非您真正了解将要构建的API调用的确切顺序。

要测试像这样的“可视化”内容，您需要三个部分。

1. 获得合适的外观、缩放比例、颜色和所有这些的“尖峰”。在某些情况下，这几乎是整个应用程序。
2. 创建一些最终图像的“手动”测试，以确保它们在某人的眼睛看来是正确的。除了实际查看输出之外，没有简单的方法来测试这一点。这很难实现自动化。
3. 模拟图形组件以确保您的应用程序正确调用图形组件。

当您进行更改时，您必须运行两个测试: API调用是否都正确？该API调用序列是否会生成看起来正确的图像？

您可以--如果您真的想要炸开一个脑细胞--尝试从您的图形创建一个PNG文件，并测试该PNG文件是否“看起来”正确。这几乎不值得你去努力。

随着时间的推移，您的需求可能会发生变化。在这种情况下，您可能必须首先重写峰值并使其看起来正确。然后，您可以提取API调用序列，以从峰值创建自动化单元测试。

有人可能会争辩说，创建峰值违反了TDD。然而，尖峰设计用于创建一个可测试的图形模块。您不能轻易地首先编写测试用例，因为测试过程是“将其显示给一个人”。它不可能是自动的。

Answer 3

您可以考虑首先将初始输入数据转换为某种可以测试的中间格式。然后将中间格式转发给实际的绘图函数，您必须手动测试该函数。

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