Question

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

是什么

上下文类的简单助记符是：“在上下文中测试功能”。（...），您测试这些功能的方式几乎取决于您测试它们的上下文。

在文档中FeatureContext似乎只是一个虚拟的上下文文件，因此您可以快速创建一个behat测试。

上下文类应该被称为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

在Behat中使用Context - 正确的方法

1 个答案: