我们已经开发了两个月的产品，它的单元测试覆盖率很高。我们大多数人也都是先写测试，然后再写代码。这意味着我们可以信任我们的测试，因为我们使用先红后绿的方法。
到目前为止，我们已经亲手向客户演示了我们的功能。然而，随着我们开始覆盖越来越多的需求，我们有必要使用功能测试来覆盖这些需求。
目前我们还没有功能测试。
我们有一个处理需求的团队成员，我相信他会是编写功能测试的好人选。不过，我担心的是，功能的开发和功能测试的编写将不同步。也就是说，在功能完全实现之前，不一定要编写测试。
从此以后，我们是否应该有一条规则，即功能测试是在功能之前编写的？换言之，先红后绿。或者还有其他方法。
如果模式对您不起作用，您不应该将自己锁定在模式中(例如，先用红色，后用绿色)。在你的情况下，我认为在你做功能性测试之前先把功能性准备好没有问题，因为你已经有了很好的单元测试覆盖率。
但只有我一个人，我相信TDD:ers会不同意的。
您要描述的方法称为行为驱动开发(BDD)。本质上，它类似于功能测试的测试驱动开发。需求或行为(或用例或场景，无论您在自己的商店中指定什么需求，都取决于您)以功能测试的形式进行描述，包括进入和退出条件，然后重复使用TDD来在您的系统中实现该行为。
一个支持BDD的简单(轻量级)开源框架被称为FitNesse。这是一个wiki风格的编辑器，用于捕获需求。在每个需求中，您都包含一个示例请求和结果表，然后Fitnesse会自动调用服务并为您进行测试。它不是最好的工具，我也不认为它能很好地扩展，但你可以很快上手。另一个工具(比FitNesse更好，或者我听说过)是soapUI。它更完整，可以做一些事情，比如代替缺失的服务、进行负载测试、组织测试等等。
TDD和BDD之间的一个区别是，在BDD中，根据行为的性质，您的功能测试可能是完全自动化的，也可能不是完全自动化的。自动化程度越高越好，但有时让人运行脚本或观察一些结果会更容易。BDD所需的测试环境也可能更加复杂，包含了实际的数据库和服务。虽然这意味着您可以以现实的方式对行为进行全面测试，但这也意味着您必须拥有一个充满应用程序所依赖资源的测试环境。这不是一件坏事，这只是你的测试变得真实的地方。