计划写在基于单元生成的代码测试

Question

正如我在做测试驱动开发我考虑是否一个假想的程序能够完全生成的代码基于测试开发。即是否有能力拥有专门创建代码以通过测试的代码生成器。编程语言的未来只是写测试吗？

Answer 1

我认为这将是一个艰难的一个作为，至少对于这种技术的最初一代，开发人员会非常怀疑生成代码的正确性。因此人类审查也必须涉及。

由于我是什么意思一个简单的例子，假设您编写了10次测试的功能，具有样本输入和预期产出涵盖你能想到的每一个场景。一个程序可以简单地生成通过所有这些测试的代码，只不过是一个基本的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中定义，并且不需要再次测试。