Question

使用SpecFlow的任何人都可能会遇到上下文注入和方案上下文，以跨不同的绑定类存储数据。（有关更多详细信息，请参见：https://specflow.org/documentation/Sharing-Data-between-Bindings/）

作为开发人员，与上下文注入相比，方案上下文似乎非常脆弱。您使用字符串来保存和检索数据，它基本上是一个全局变量系统，在我看来，这通常是错误的。另一方面，依赖项注入可以与能够创建以存储不同类型数据的不同类很好地配合。

谁能看到您想要在上下文注入上使用场景上下文的原因吗？我什么也没想，但也许我想念什么？

Answer 1

区别：除了上下文注入，还为您提供了更好的静态类型安全性。（我写了一篇有关可以使用上下文注入建立的去中心化架构模型的文章：http://gasparnagy.com/2017/02/specflow-tips-baseclass-or-context-injection/）

为什么场景上下文？首先，此功能在上下文注入之前就已存在，并且已在许多教程等中使用。因此，它的知名度有所提高。

场景上下文在某种程度上也更容易编程。您只需获取并设置一些全局变量。对于上下文注入，您必须了解构造函数，实例字段和局部变量。我认为无论如何，这些都是重要的事情，但一次（在没有帮助的情况下）可能太多了。

当您编写通用的SpecFlow插件并且您不希望依赖于具体项目的依赖项管理系统的详细信息时，场景上下文也可能有用，但这还是很特殊的情况。

Answer 2

场景上下文正在使用字符串。这意味着您可以将字符串作为测试的参数传递。您可以编写一个通用的测试方法以将某些内容存储在Scenario Context变量中。例如：

public void GenericSaveIntTestMethod(string variableName, int intToSave){

    ScenarioContext.Current[variableName] = intToSave;

}

您可以重用它。用不同的名称保存不同的int。我不确定这是好事还是坏事，但是我已经在工作的框架中看到了它的用法。我不确定是否可以使用上下文注入来做到这一点。