在 Behat 中使用上下文 - 正确的方法

Question

在 behat 中使用 FooContext 类的正确方法是什么？

docs 是什么：

上下文类的一个简单助记词是：“在上下文中测试特征”。 (...)，您测试这些功能的方式很大程度上取决于您测试它们的环境。

在文档中FeatureContext 对我来说似乎只是一个虚拟上下文文件，以便您可以快速创建一个行为测试。

上下文类应称为 FeatureContext。这是 Behat 基础架构中的一个简单约定。 FeatureContext 是默认套件的上下文类的名称。

它并没有直接告诉我它必须是每个功能的上下文文件。

文档中唯一真实的其他示例是 ApiContext 或 WebContext 等上下文。

default:
    suites:
        web_features:
            paths:    [ %paths.base%/features/web ]
            contexts: [ WebContext ]
        api_features:
            paths:    [ %paths.base%/features/api ]
            contexts: [ ApiContext ]

我还发现了一个CommandFeature 和另一个CommandLineProcessContext。

所以如果我有很多功能要测试，上下文文件会很快爆炸。

然后我看到Marco Pivetta 使用Aggregate as Context 的每个功能示例更可能是一个上下文文件。

每个功能都有一个上下文文件foo.feature 是个好主意吗？或者上下文文件是否被认为是文档ApiContext 或WebContext 中的环境上下文？

Answer 1

通常我更喜欢将上下文和特征划分如下：

• 每个域主题一个文件夹
• 您可以对此主题执行的每个操作都有一个功能/上下文文件

这样您最终会得到一个使用多个上下文但所有上下文划分为单一职责的单个套件。

快速示例

Features
|--- User
|----- login.feature
|----- change_password.feature
|----- impersonate.feature
|----- ban.feature
|----- ...
|--- ...
|--- Order
|----- checkout.feature
|----- cancel.feature
...
Context
|--- User
|---- LoginContext
|---- ChangePasswordContext
|---- ImpersonateContext
|---- BanContext
|---- ...
|--- Order
|---- CheckoutContext
|---- CancelContext

每个套件都由许多上下文组成（例如，每次您需要登录以检查行为时，您都会在套件中包含LoginContext）。

default:
  suites:
    suite_name:
      paths:
        - '%paths.base%/Path/To/Feature/File'
      contexts:
        - Path\To\Context\LoginContext
        - Path\To\A\SecondContext
        - ...

这种方法在可维护性、直观性等方面有很多优势。

如果您想对该主题有更通用的全景，您可以check slides from my talk at Symfony day 2017 in Milan