多部分 Codecept.js 场景的首选(或只是一个好的)模式是什么,例如:
- 选择要上传的文件。
- 清空选项。
- 清除选择后选择要上传的文件。
我可以在单个场景中执行此操作并用于I.say
描述部分,但感觉我应该能够将这些作为独立场景编写并.only
在第 2 部分中使用,例如,第 1 部分在第 2 部分之前运行,因为它取决于它。
如果在运行整个套件时第 1 部分失败,我也想跳过第 2 部分和第 3 部分。
多部分 Codecept.js 场景的首选(或只是一个好的)模式是什么,例如:
我可以在单个场景中执行此操作并用于I.say
描述部分,但感觉我应该能够将这些作为独立场景编写并.only
在第 2 部分中使用,例如,第 1 部分在第 2 部分之前运行,因为它取决于它。
如果在运行整个套件时第 1 部分失败,我也想跳过第 2 部分和第 3 部分。
我喜欢从能力的角度来思考行为。我可以看到你在这里有一对:
所以我希望这些在两种情况下:
很多人说场景中应该只有一个“时间”,但这并没有考虑到与人的互动(包括你过去错误的自我)或时间。在这种情况下,提供价值的是纠正文件上传的整个过程。我在中间步骤中看不到任何价值,所以我会将它们全部放在一个场景中。
如果有任何与不同上下文相关的不同行为(例如:您已经上传了太多文件)或结果(例如:您的文件系统没有空间)或规则(例如:您的状态意味着您有资格获得超快上传)然后我希望那些是新的场景。如果您开始发现有很多与文件上传相关的场景以及发生在它们身上的不同事情,那么这可能是分离这种场景的好时机。现在我看不出有任何理由这样做。
第一部分失败了:如果你做的 BDD 是正确的,那么你不仅会讨论系统的行为,还会讨论各个代码位的行为。这应该有助于产生一个好的设计,最大限度地减少出现错误的机会。真正优秀的 BDD 团队会产生几乎不会发现错误的场景!
这些场景充当活文档,而不是回归测试;帮助未来的开发者理解代码的价值并把它做对,而不是为了阻止他们犯错而把它钉牢。
所以我不会担心它会失败。如果它做的很多,你就会遇到一个不同的问题。对它进行编码,就好像它大部分时间都会过去一样,并确保它的可读性和可理解性。只要你能看到它何时失败并解决它,即使这需要一点时间,它会没事的。
话虽如此,如果 Codecept 至少没有停止失败的选项,我会感到惊讶。大多数 BDD 工具在步骤失败后不会继续场景;这将是一件奇怪的事情。
据我所知,您无法在 codeceptjs 中设置执行优先级。最好做一个测试。如果您需要添加或删除某些部分,它也会更加灵活。