tdd - 伪代码编程过程与测试驱动开发

Question

对于没有读过 Code Complete 2 的人来说，Pseudocode Programming Process 基本上是一种设计例程的方法，先用通俗的英语描述它，然后逐渐将其修改为更详细的伪代码，最后进行编码。这样做的主要好处是通过自顶向下而不是自底向上构建系统来帮助您保持在正确的抽象级别，从而在不同的层中演化出干净的 API。我发现 TDD 在这方面不太有效，因为它过多地专注于做最低限度的工作来让测试通过，并鼓励很少的前期设计。我还发现，必须为不稳定的代码(不断重构的代码)维护一套单元测试是相当困难的，因为通常情况下，您对一个只需要一两次的例程进行十几个单元测试。当您进行重构时 - 例如更改方法签名 - 您所做的大部分工作是更新测试而不是产品代码。我更喜欢在组件的代码稳定一点后添加单元测试。

我的问题是 - 在尝试过这两种方法的人中，您更喜欢哪个？

Answer 1

我的团队混合了这两种方法，这是一种很棒的开发方式(至少对我们而言)。我们需要单元测试，因为我们有一个庞大而复杂的软件系统。但是伪代码编程过程是我遇到的最好的软件设计方法。使它们协同工作:

我们从编写类开始，
并填写完整评论
方法 stub ，带有输入和
输出。

我们使用配对编码和同行评审作为对话来改进和验证设计，但仍然只使用方法 stub 。

在这一点上，我们现在已经设计了我们的系统并有一些可测试的代码。所以我们继续编写我们的单元测试。

我们返回并开始用需要编写的逻辑的注释填充方法。

我们写代码；测试通过。

它的美妙之处在于，当我们真正编写代码时，大部分实现工作已经完成，因为我们认为的实现实际上是代码设计。此外，早期的过程取代了对 UML 的需求——类和方法 stub 同样具有描述性，而且它会被实际使用。我们始终保持在适当的抽象级别。

显然，这个过程从来没有像我所描述的那样线性——实现的一些怪癖可能意味着我们需要重新审视高级设计。但总的来说，当我们编写单元测试时，设计确实非常稳定(在方法级别)，因此不需要大量的测试重写。