0

假设我有一个主要的 python 行为特征文件，在所述文件中，我检查是否存在 25 个，给予或接受，特征文件，以正确的顺序运行它们中的每一个，然后验证一些后置条件。

如果可能的话，我希望能够在单个功能文件中测试多个功能。我写了这一步：

@when(u'Feature {name} is executed')
def step_meta_feature(context, name):
    context.script_start_time = datetime.datetime.now()
    print("Testing feature " + name)
    os.system("behave " + name + ".feature --no-capture")
    context.script_end_time = datetime.datetime.now()

目前，只要在主功能文件的@when 子句中执行某个功能，此步骤将始终成功运行。我相当肯定这是因为它没有检查任何条件，如果执行了一个行为脚本，无论它是否失败，这一步都会通过。

为了解决这个问题，我想在这一步或 environment.py 文件的 after_feature() 函数中添加一行，以检查执行的行为特征是否通过。

Behave 的 API 确实说它包含一个从特性文件创建的特性对象，它返回一个“状态”变量，告诉你特性是通过还是失败。但是，该状态变量似乎只能在 environment.py 文件中访问。

我的想法是，我会找到一种方法来使用行为的功能而不是 os.system 从步骤中执行功能对象，然后检查其状态，但我不知道这是否可能。或者，我知道我可以编写一个按顺序执行 25 个场景的功能文件，但文件中包含所有场景。但是我想避免这样做，因为主脚本被分成 25 个较小的脚本用于单独的测试目的。此外，拥有几个较小的功能和一个大功能以执行同一文件夹中所有较小功能的功能并以任意顺序运行也不是一个好主意。

如果来自另一个文件的功能通过或失败，我如何从 environment.py 或 steps.py 中检查？

编辑：我猜的另一个想法是找到一种方法将发送到命令行的文本输出到功能日志文件并阅读最后几行以查找是否有任何功能或步骤失败，尽管这看起来像迂回的做事方式。

4

2 回答 2

0

我不知道你是否还在寻找这个问题的答案，

我个人不建议使用主功能文件。

我建议在您运行行为的顶级文件夹中设置另一个名为 environment.py 的 python 脚本。

在此文件中，您可以使用以下内容：

    def after_feature(context, feature):
            if context.failed:
                    print('Failed')
            else:
                    print('Passed')

顾名思义，behaviour 会在每个特征文件执行完毕后调用这个函数

或者，如果您正在寻找更通用的通过/失败日志和功能名称：

    def after_feature(context, feature):
            print('The feature: ' + feature.name + ' ' + feature.status)
于 2015-12-08T05:05:22.020 回答
0

最大的问题是——你到底为什么需要它？如果特征 X 依赖于特征 Y，那么它们都将失败。如果额外的功能是某种诊断，为什么不每次都运行它呢？“额外诊断”是我唯一可以想象到的可能有用的场景（并且仍然在 BDD 约定范围内），但坦率地说，每次都应该运行它以确保一切都按预期工作。

唉，如果由于某种原因你不能拥有它，那么处理它的最佳方法是在 BDD 之外，但在你的 CI 内部（持续集成，例如 TeamCity）。因此，您可以创建每组功能作为构建步骤，并且可以为特定步骤失败设置触发器。

但是我在这里的感觉是，您只是拥有不完全是 BDD 的 .feature 文件，而现在您正试图弯曲该工具以匹配它。因此，最好的解决方案可能是重新考虑它们。

于 2015-07-26T00:23:08.863 回答