为我不明白目的的代码编写测试

我最近完成了黑盒重构。我无法检入它，因为我无法确定如何进行测试。

在较高的层次上，我有一个其初始化涉及从某些类B获取值的类。如果类B为“空”，它将生成一些合理的默认值。我将这一部分提取到一种方法中，该方法将B类初始化为相同的默认值。

我还没有弄清这两个类的目的/背景，或如何使用它们。因此，我无法从空的类B初始化对象并检查其是否具有正确的值/是否做正确的事情。

我最好的主意是运行原始代码，根据初始化的成员在公共方法的结果中进行硬编码，然后对此进行测试。我不太清楚为什么我对这个想法含糊不清。

这里有更好的进攻方式吗？

你还好！

创建自动化回归测试通常是使组件可重构的最佳方法。可能令人惊讶，但是只要您了解输入和输出“接口”（按该词的一般含义），通常就可能在不完全了解组件内部功能的情况下编写此类测试。过去，我们对成熟的遗留应用程序（不仅是类）进行了几次这样的操作，它通常可以帮助我们避免破坏我们不完全了解的内容。

但是，您应该具有足够的测试数据，并确保从该组件用户的角度对软件的功能有深刻的了解，否则可能会忽略重要的测试用例。

恕我直言，在开始重构之前（而不是在重构之后）实施自动化测试是一个好主意，因此您可以分步进行重构，并验证每一步。重构本身应该使代码更具可读性，因此它可以帮助您逐步了解内部。因此，此过程中的订购步骤为

1. 理解代码“从外部”，
2. 编写回归测试，
3. 重构，从而可以更好地理解代码的内部结构

编写单元测试的一个重要原因是它们以某种方式记录了组件API。在这里，不了解被测代码的目的确实是一个问题。代码覆盖率是另一个重要目标，如果不知道存在哪些执行分支以及如何触发它们就很难实现。

但是，如果可以干净地重置状态（或每次构造新的测试对象），则可以编写“垃圾进垃圾出”类型的测试，该测试仅将大部分随机输入馈入系统并观察输出。

这样的测试很难维护，因为当它们失败时，说出原因和严重程度可能很复杂。覆盖范围可能令人怀疑。但是，它们总比没有好。当此类测试失败时，开发人员可以更加关注地修订最新的更改，并希望在那里发现该错误。