c# – Specflow中的依赖注入,它是每个功能的一个上下文对象吗？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了c# – Specflow中的依赖注入,它是每个功能的一个上下文对象吗？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1463字，纯文字阅读大概需要3分钟。

内容图文

在Specflow中,可以使用dependency injection在步骤定义之间共享上下文

这是否意味着您最终为每个功能提供了不同的“上下文”类？

如果是这样,这不会使跨功能共享步骤定义变得不切实际吗？你认为已经设置了字段吗？

解决方法:

Does this mean that you end up with a different “context” class for each feature?

我不认为会是这种情况.在编写规范时,您肯定会提到系统的几个“类型”部分.假设我们有以下情况：

Scenario: List todo items
  Given I'm registered as user@example.com
  And I'm logged in as user@example.com
  And I add a todo item with the text 'Listen to stackoverflow podcast'
  When I list all my todo items
  Then I should see the following items
    | Text                            | Completed |
    | Listen to stackoverflow podcast | false     |

在这种情况下,我们正在与系统的几个部分进行交互：

>注册
>认证
> TodoItem创作
> TodoItem上市

在实现此功能的步骤时,我们最终可能会得到如下组织的步骤文件：

> AuthSteps

>鉴于我注册为__
>鉴于我以__身份登录

> TodoItemsSteps

>我添加了一个带有文本’__’的待办事项
>当我列出所有待办事项时
>然后我应该看到以下项目

在这种情况下,使用上下文注入,我们希望共享CurrentUser的值,以便能够说出“当我列出所有我的待办事项”时,引用当前用户.这样,任何其他stepFile中的任何其他步骤都可以是先前步骤的上下文.

另一方面,我不会将上下文注入与我列出所有待办事项时的结果一起使用,因为分享这些特定功能问题的唯一步骤将在同一个功能文件中.您可以拥有当时“声明”的多个变体,就像那时我应该看到n个项目.

虽然我认为您可能有多个类使用上下文注入来共享您正在构建的服务的依赖关系,或者可能是服务本身(存储,会话等…)

内容总结

以上是互联网集市为您收集整理的c# – Specflow中的依赖注入,它是每个功能的一个上下文对象吗？全部内容，希望文章能够帮你解决c# – Specflow中的依赖注入,它是每个功能的一个上下文对象吗？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端