unit-testing - 用基于单元测试的生成代码编写的程序

Question

在进行测试驱动开发时，我思考是否可以完全通过基于测试生成的代码来开发假设的程序。即是否有能力拥有一个专门创建代码以通过测试的生成器。编程语言的未来只是编写测试吗？

Answer 1

我认为这将是一个艰难的过程，因为至少对于此类技术的最初几代来说，开发人员会非常怀疑生成代码的正确性。因此，人工审查也必须参与。

作为我的意思的一个简单说明，假设你为一个函数编写了 10 个测试，样本输入和预期输出涵盖了你能想到的每个场景。一个程序可以简单地生成通过所有这些测试的代码，只需要一个基本的 switch 语句（你的十个输入与它们的预期输出匹配）。这段代码显然是不正确的，但需要人类才能看到。

这只是一个简单的例子。不难想象更复杂的程序可能不会生成 switch 语句，但仍会产生实际上不正确的解决方案，并且可能以更微妙的方式出错。因此，我的建议是，任何沿着这些思路的技术都会遭到深层次的怀疑，至少在开始时是这样。

Answer 2

如果代码可以完全生成，那么生成器的基础必须是准确描述代码的规范。这个生成器就像一个编译器，将一种语言交叉编译成另一种语言。

测试不是这样的语言。他们只断言代码功能的特定方面是有效的并且没有改变。通过这样做，他们构建了代码，使其不会中断，即使在重构时也是如此。

但是我如何比较这两种发展方式呢？

1）如果生成器工作正常，那么规范总是被转换成正确的代码。我假设这段代码是经过设计测试的，不需要额外的测试。生成器比生成的代码更好的 TDD。

2) 在我看来，无论您是否有导致生成代码的规范或表示为确保代码有效的测试的规范，都相当等价。

3）您可以结合两种开发方式。使用经过测试的生成器从规范生成程序框架，然后使用 TDD 丰富生成的代码。注意：然后您将在一个项目中运行两个不同的开发周期。这意味着，您必须确保在规范更改时始终可以重新生成生成的代码，并且您的附加代码仍然正确地适合生成的代码。

只是一个小例子：想象一个可以从 UML 类图生成代码的工具。这可以通过您可以使用 TDD 开发方法的方式来完成，但类的结构是在 UML 中定义的，您不需要再次测试。

Answer 3

虽然将来有可能，但可以使用简单的测试来生成代码：

assertEquals(someclass.get_value(), true)

但是我猜想从黑盒集成测试中获得正确的输出是一个 NP 完全问题：

assertEquals(someclass.do_something(1), file_content(/some/file))

assertEquals(someclass.do_something(2), file_content(/some/file))
assertEquals(someclass.do_something(2), file_content(/some/file2))

assertEquals(someclass.do_something(3), file_content(/some/file2))

这是否意味着生成的代码将始终写入/some/file？这是否意味着生成的代码应该始终写入/some/file2？两者都可能是真的。如果它只需要做最小的设置来让测试通过怎么办？在不了解上下文并编写非常精确和有界的测试的情况下，任何代码都无法（此时）弄清楚测试作者的意图。