c# - 这些是什么类型的测试，应该编写它们吗？

Question

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

考虑到这一点，我们坐下来创建了一个功能列表，这些功能将完全涵盖我们所需要的，仅此而已。当您查看此“规范”时，它不包括接口(interface)抽象或配置之类的内容，事实上，一个漂亮的流畅接口(interface)会把大部分项目从列表中剔除。

所以现在提示在我面前闪烁，我不知道该写什么。我以前做过单元测试，但我们发现如果您创建某种场景并验证它通过，则这些单元测试对于更大的对象或以更具凝聚力的方式进行测试是缺乏的。不要将此误认为是对单元测试的打击，我认为它更多地与我们有关，而不是与单元测试有关。呼呼

我突然想到以下几点。

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

  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，并且在确定基线时真的不想增加任何复杂性。

Answer 1

对我来说，这听起来像是一个组件测试。 HTTP 请求需要考虑的一件事是，不要只寻找 OK 响应，还要快速检查内容。如果您期望格式良好的 HTML 返回可能会寻找出现在静态错误页面上的独特单词或短语，或者如果您期望 JSON 或 XML 认为正确的响应看起来像是错误。