【问题标题】:Protractor/Jasmine Conditional Test CasesProtractor/Jasmine 条件测试用例
【发布时间】:2016-10-11 10:20:17
【问题描述】:

与此问题相关:How can I create conditional test cases using Protractor? -- 我很好奇这些场景是否有合法(记录在案)的答案,因为我无法得到直接的答案。

虽然链接问题中发布的ignore 解决方案有效,但从风格上讲,我不喜欢它。乍一看,您似乎在忽略/跳过规范。

另外,我在Gitter 上问过这个问题——下面的代码是不好的做法吗?

if(questionAnswer == "Yes") {
   it('should display another question', function() {
       // code
   });
}

我从 Protractor 团队的某个人那里收到的关于 Gitter 的回答相当含糊:

这可能会导致不稳定的测试...我认为没有什么可以说这是不错的做法。如果它对您有用,请使用它。

我对这个答案不满意,因为他以“可能是片状的”开头......这对我来说听起来不太稳定。我看到的唯一选择是在规范中正常创建条件,并创建任意断言来捕获else 场景,即:

it('should display another question', function() {
    if(questionAnswer == "Yes") {
        expect(question2.isDisplayed()).toBe(true);
    }
    else {
        expect(true).toBe(true);
    }
});

但是我会自动添加一个额外的测试用例,而它只需要 50% 的时间。我知道这是一个小问题,但它确实困扰着我。

上面的代码是我目前面临的情况 - 如果最后一个规范回答“是”,我需要为下一个问题运行一个额外的规范。如果没有,那我的测试就结束了。真的没有官方方法可以在 Jasmine/Protractor 中有条件地运行规范吗?

【问题讨论】:

  • questionAnswer 在做什么?它是跟踪代码的状态吗?考试?环境?
  • 这只是一个反映其帐户特权的布尔值。如果他们有能力,那么我还有另一个测试用例。如果没有,那我就没有。
  • 所以它是影响您正在测试的代码的上下文/状态?也就是说,特权帐户的代码行为不同?
  • 是的。通常我会为不同的行为制作 2 个单独的测试文件,但除了最后一种情况外,整个 e2e 测试都很好。如果用户拥有此权限,它实际上只是向用户显示的额外信息行。所以我认为把它作为一个测试文件保存是有意义的。

标签: angularjs jasmine protractor


【解决方案1】:

在这些情况下,我使用所谓的上下文。通常,上下文用于表示影响您正在测试的代码行为的状态更改。

虽然 Jasmine 中没有明确提供,但它们确实存在于其他 BDD 样式的测试框架中,例如 Rspec (related reference)。通常,context 只是 describe 的别名。

所以在 Jasmine 中,我将使用 describe 并将我的测试结构如下:

describe('someMethod', function() {
    describe('when a privileged account', function() {
        beforeEach(function() {
           questionAnswer = "Yes";
           someMethod();
        });

        it('should do something', function() {
            // expectation
        }
    });

    describe('when not a privileged account', function() {
        beforeEach(function() {
           questionAnswer = "No";
           someMethod();
        });

        it('should do something else', function() {
            // expectation
        }
    });
);

我避免使用“条件测试”。我宁愿运行更多测试以确保我已经用尽了所有代码路径。此外,我发现测试更具可读性,这是 BDD 风格测试的目标之一。

最后,在测试中添加逻辑是人们走上荒谬的测试测试之路的原因之一。然后测试测试测试的测试。然后……

【讨论】:

  • 这是有道理的,避免条件/逻辑是对的。我想我以为我试图让测试更简洁和灵活,但我真的很懒:)。绝对更好地涵盖所有场景。谢谢。
猜你喜欢
  • 1970-01-01
  • 2019-02-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多