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