我们最近开始讨论测试。我们想要的测试类型之一是某种功能或验收测试。希望是减少浪费的开发并拥有一些可自我验证的软活文档。我们作为概念证明提出的示例是构建一个 http 客户端，我们选择这个是因为它很快就会变得非常复杂，如果你不小心，你可能会在几天内开发，添加一些小的边缘案例处理程序等.
考虑到这一点，我们坐下来创建一个功能列表，该列表将完全涵盖我们需要的功能，仅此而已。当您查看此“规范”时，它不包括接口抽象或配置之类的东西，事实上，一个漂亮的流畅接口会将大多数项目从列表中剔除。
所以现在提示对我闪烁，我不知道该写什么。我之前做过单元测试，但我们发现这些对于更大的对象或以更有凝聚力的方式进行测试是缺乏的，如果你创建了某种场景并验证它通过了。不要把这误认为是对单元测试的打击，我想它更多地与我们有关，而不是与单元测试有关。随便
在我的脑海中，我正在考虑以下内容。
写一个场景，一个例子会是这样的：
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，并且在我们确定基线时真的不想增加任何复杂性。