Question

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

Answer 1

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

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

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

Answer 2

虽然将来某个时候可以使用，但可以使用简单的测试来生成代码：

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？两者都可能是真的。如果它只需要执行最小集以使测试通过怎么办？在不知道上下文并编写非常精确和有界的测试的情况下，没有代码能够（在这个时间点）找出测试作者的意图。

Answer 3

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

测试不是这样的语言。他们只断言代码功能的特定方面是有效且不变的。通过这样做，他们支持代码，以便它不会破坏，即使它被重构。

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

1）如果发电机正常工作，则规范始终转换为正确的代码。我假设这个代码是按设计测试的，不需要额外的测试。比生成的代码更好的TDD生成器。

2）你是否有一个规范，导致生成的代码或规范表示为测试，以确保代码工作在我眼中是完全相同的。

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

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

基于单元测试以生成的代码编写的程序

3 个答案: