Question

假设我有一个主要的python-behave功能文件，并且在所述文件中，我检查是否存在25，给予或接受特征文件，以正确的顺序运行每个文件，然后验证一些后置条件。< / p>

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

@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确实说它包含一个Feature对象，该对象是根据要素文件创建的，它返回一个“状态”变量，告诉您该功能是通过还是失败。但是，该状态变量似乎只能在environment.py文件中访问。

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

如果来自其他文件的功能通过或失败，我如何在environment.py或steps.py中检查？

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

Answer 1

最大的问题是 - 为什么你需要那个？如果特征X依赖于特征Y，那么它们都将失败。如果额外的功能是某种诊断，为什么不每次都运行它？ “额外诊断”只是我可以想象的情况，这可能是有用的（并且仍然在BDD惯例中），但坦率地说，每次都应该运行它以确保一切按预期工作。

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

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

Answer 2

我不知道你是否还在寻找答案，

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

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

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

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

正如方法名称所示，在每个特征文件完成执行后，actve会调用此函数

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

    def after_feature(context, feature):
            print('The feature: ' + feature.name + ' ' + feature.status)

如何确定（Python）行为特征文件是否在步骤文件中成功运行？

2 个答案: