SpecFlow -上下文注入与场景上下文

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

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

public void GenericSaveIntTestMethod(string variableName, int intToSave){

    ScenarioContext.Current[variableName] = intToSave;

}

你可以重复使用它。用不同的名字保存不同的int。我不确定这是一个好的实践还是坏的实践，但我已经在我正在工作的框架中看到过它。我不确定是否有一种方法可以通过上下文注入来做到这一点。