我应该在原型开发/测试准备过程中进行单元测试吗？

Question

我正在为一个迫切需要它的行业开发一个网络应用程序。与业内的一位顾问合作，我在两个月内迅速开发了一个原型，我们将与一家他们咨询的公司进行测试。该软件将用于测试它的4-8名员工。

当我与顾问一起将行业需求转化为可用的软件时，原型一直在不断地变化。昨晚我举行了一次会议，巩固了4个特性/关注点，如果我做了TDD，就会浪费大约8个小时，因为测试和代码都会被丢弃。

到目前为止，我的过程是：

1. 检查员工正在使用他们当前的操作软件。
2. 听取顾问关于哪些需要更改，哪些是低效的，等等，并对新软件中的潜在功能进行记录。
3. 快速原型没有编写测试(已经非常成功，顾问和贝塔员工都兴奋地开始使用它，因为这样可以节省大量的时间)
4. 从顾问那里获得反馈，并根据需要进行调整
5. 重复1-4次

这是可行的，但我想知道我是否应该一直在编写测试。我已经完成了大约200个小时的开发，并且可能有大约150个小时的测试时间(复杂的行业规则需要测试！)，但我几乎没有跟上开发工作的进度。

在我看来，测试之前的测试将是一个巨大的时间接收器，特别是因为需求正在发生变化。我的大部分功能都是正确的，但是一些小的东西，特别是与行业规则有关的，已经改变了。所以花时间为那些我一开始就做不好的事情写测试会浪费大量的时间.看来是这样。

在我们完成原型开发之前，我是否正确地等待编写测试，在测试中，不仅有顾问的反馈，而且还有测试人员的反馈？还是我犯了个大错？

Answer 1

我从事过没有测试、开发驱动测试和实际红绿重构TDD的项目，您所描述的是我在尝试实际TDD之前可能编写的一些东西。

我在两个月内迅速开发了一个原型，我们将与一家他们咨询的公司进行测试。该软件将用于测试它的4-8名员工。

原型的源代码会在测试之前扔掉吗？如果是这样的话，您可能已经正确地避免了TDD，至少对于代码库的简单部分--这样一个原型的目的是学习或证明一些事情是可行的。如果没有，那么您已经编写了遗留代码，并且会发现，在不破坏任何东西的情况下进行更改的难度随着软件的复杂性而迅速上升。这是我见过的每一个非TDD代码的例子，还有很多DDT代码。

昨晚我举行了一次会议，巩固了4个特性/关注点，如果我做了TDD，就会浪费大约8个小时，因为测试和代码都会被丢弃。

这是一个普通的草人论点。首先，在非TDD工作上花费的精力并不等同于TDD工作，因为您最终会得到不同的代码。在这方面，您只需相信我；我从未见过任何非TDD代码，这些代码很容易编写自动化测试。其次，我从实际TDD中得出的结论是，编写测试和特性比仅仅编写特性更快。

我已经完成了大约200个小时的开发，并且可能有大约150个小时的测试时间(复杂的行业规则需要测试！)，但我几乎没有跟上开发工作的进度。

同样，在我的经验中，即使在不断变化的需求下，如果您正在执行TDD，您的速度也会更高。

在我看来，测试之前的测试将是一个巨大的时间接收器，特别是因为需求正在发生变化。

同样，如果简单地将编写特性的时间和编写测试的时间相加，这就是典型的视图。但以我的经验来看，滴滴涕看起来是这样的：

1. 用1单位时间写代码
2. 在0.5到2个单位的时间内编写测试

您的应用程序现在更难修改以实现下一个功能。而TDD看起来是这样的：

1. 用一个单位的时间写测试
2. 在0.1-0.5单位的时间内编写代码，因为到目前为止，您应该确切地知道需要更改什么以及如何更改
3. 在0.1-0.2单位时间内重构

您的应用程序现在更难修改0.2个单元。如果开始测试遗留应用程序，这些数字将是非常不同的，但您应该会看到在应用程序测试部分中更改时间的时间有了明显的改进。

另一方面，实际的TDD是困难的。需要一位熟练的导师来演示它，并且需要很长的时间来学习所有必要的技术，以避免达到不可维护的测试集。我想我可以诚实地说，这是我作为一个程序员所学到的最难的事情，而且我还没有完成学习--尤其是在测试中避免大量的上下文是很困难的。