这些是什么样的测试?应该写出来吗

我们最近开始讨论测试。我们想要的测试类型之一是某种功能测试或验收测试。希望是减少浪费的开发，并拥有一些软的活文档，这些文档也可以自我验证。我们提出的概念验证的例子是构建一个http客户端，我们之所以选择这个，是因为它可能会很快变得非常复杂，如果你不小心，你可能会在几天内开发添加一些小的边缘案例处理程序等。

考虑到这一点，我们坐下来创建了一个功能列表，该列表将完全涵盖我们需要的内容，不再需要。当你看这个"规范"时，它不包括接口抽象或配置之类的东西，事实上，一个好的流畅接口会把列表中的大多数项都去掉。

所以现在提示在我面前闪烁，我不知道该写什么。我以前做过单元测试，但我们发现，如果你创建某种场景并验证它通过了，那么对于更大的对象或更具凝聚力的测试来说，这些都是缺乏的。不要把这误认为是对单元测试的打击，我想这更多地与我们有关，而不是与单元测试有关。Anyhoo

我的脑海里浮现出以下想法。

• 写一个场景，一个例子如下：

  Create a new http request. 
  This request should should be a GET request.
  It should have no body.
  It should have reasonable defaults already defined.
  

• 实施场景：

  var request = 
  new httpRequest().UsingMethod(HttpMethods.Get)
                   .WithDefaultHeaders();
  

不过，我对此感到担忧。一方面，它非常完美。我已经满足了这个场景，我可以添加更多的场景来感受其他需求。另一方面，我通常会先开发出整个东西，然后进行测试，所以感觉我失去了对功能架构的控制。

我想知道的是：

• 这种类型的测试正常吗？人们使用它吗？它有名字吗？

• 我是走在正确的道路上，还是最终会做出大量的架构假设？

• 在进行此类测试或分析时，体系结构适用于何处。有一个完成的定义是很好的，就像上面（规范已经完成），但在某个地方，某种架构必须完成，对吗？

最后。我想让这个工具不可知。我们正在使用C#和xUnit，在计算基线时，我们真的不想增加任何复杂性。